cometd + Jetty6.1.26 NoClassDefFoundError

[donp]

I am trying to get set up initially with cometd running in a Jetty
6.1.26 container.

I've got the cometd JAR files and have modified the web.xml as needed,
but when the CometdServlet loads I see a NoClassDefFoundError:

java.lang.NoClassDefFoundError: org/eclipse/jetty/util/component/
AbstractLifeCycle
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:
165)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:
554)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:
524)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:
455)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:
443)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:
423)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:
193)
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:
368)
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:
444)
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:
397)
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:
385)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:
87)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at org.cometd.server.CometdServlet.newBayeuxServer(CometdServlet.java:
145)


Since this seems to be referring to the AbstractLifeCycle class by the
package naming of Jetty 7 (with the eclipse namespacing), this makes
me think that there's an assumption of using Jetty 7 with cometd, and
that there is no compatibility with Jetty 6, which has a different
package naming structure.

Or, is there some JAR file or web.xml setting that I may be missing?

The JARs I'm using are:

cometd-java-common-2.4.2.jar
bayeux-api-2.4.2.jar
cometd-java-server-2.4.2.jar

plus the standard binary JARs from Jetty 6.1.26.

Any help or suggestions would be appreciated.

Thanks,
Don P.

[donp]

I have also tried using the cometd implementation from the jetty-
contrib project, but this will not work with Cometd2, because again,
the package naming has changed in Cometd.

Since the jetty-contrib implementation of cometd relies on org.cometd
packages, the jetty-contrib implementation breaks due to the changed
org.cometd packaging.

Again, any help appreciated.

Thanks,
Don P.

[Simone Bordet]

Hi,

On Tue, May 22, 2012 at 12:12 AM, donp <don...@gmail.com> wrote:
> I am trying to get set up initially with cometd running in a Jetty
> 6.1.26 container.

Not really recommended, unless you can't change Jetty version.
Jetty 7 (for servlet 2.5) and Jetty 8 (for servlet 3.0) are the
current most updated Jetty versions.

> I've got the cometd JAR files and have modified the web.xml as needed,
> but when the CometdServlet loads I see a NoClassDefFoundError:
>
> java.lang.NoClassDefFoundError: org/eclipse/jetty/util/component/
> AbstractLifeCycle
>

> Since this seems to be referring to the AbstractLifeCycle class by the
> package naming of Jetty 7 (with the eclipse namespacing), this makes
> me think that there's an assumption of using Jetty 7 with cometd, and
> that there is no compatibility with Jetty 6, which has a different
> package naming structure.
>
> Or, is there some JAR file or web.xml setting that I may be missing?
>
> The JARs I'm using are:
>
> cometd-java-common-2.4.2.jar
> bayeux-api-2.4.2.jar
> cometd-java-server-2.4.2.jar
>
> plus the standard binary JARs from Jetty 6.1.26.

You are missing the required Jetty7 jars.
This is the expected content of WEB-INF/lib:

WEB-INF/
├── classes
├── lib
│   ├── bayeux-api-2.4.2.jar
│   ├── cometd-java-common-2.4.2.jar
│   ├── cometd-java-server-2.4.2.jar
│   ├── jetty-continuation-7.6.3.v20120416.jar
│   ├── jetty-jmx-7.6.3.v20120416.jar
│   ├── jetty-util-7.6.3.v20120416.jar
│   ├── slf4j-api-1.6.4.jar
│   └── slf4j-simple-1.6.4.jar
└── web.xml

You can use the Maven archetypes to generate a skeleton web
application for Jetty 6, and start from there.
Follow: http://docs.cometd.org/reference/#primer_maven_way

Simon
--
http://cometd.org
http://intalio.com
http://bordet.blogspot.com
----
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

[Simone Bordet]

Hi,

On Tue, May 22, 2012 at 12:40 AM, donp <don...@gmail.com> wrote:
> I have also tried using the cometd implementation from the jetty-
> contrib project, but this will not work with Cometd2, because again,
> the package naming has changed in Cometd.
>
> Since the jetty-contrib implementation of cometd relies on org.cometd
> packages, the jetty-contrib implementation breaks due to the changed
> org.cometd packaging.

Don't use it: it's old and not maintained anymore.
Follow instructions in the other email.

[donp]

Simone,

Thank you very much for your quick reply.

I've updated my /lib area with the additional JAR files, and now the
CometdServlet is loading as expected. So, thanks for that.


A couple of comments on your notes/questions above -

My situation is very similar to this poster's situation -
http://groups.google.com/group/cometd-users/browse_thread/thread/c38f6ebe7d4c3ca3/eda5674c69a19a3f?lnk=gst&q=jetty+6#eda5674c69a19a3f

I must use Jetty6, because I am working on a very large enterprise
project with strict security/vulnerability criteria, which newer
versions of Jetty do not yet meet. Additionally, migrating to a new
Jetty version is not a simple matter, because of the complexity of the
project and other Jetty dependencies (like a SSO implementation).

I do not use Maven, because again, my organization has an existing
code repository and build system that is not Maven.


So, with this, I followed the instructions and the primer, for the non-
Maven case. However, while there is a place in the "non-Maven"
section that shows the /lib directory structure as:

│ ├── lib
│ │ ├── bayeux-api-[version].jar
│ │ ├── cometd-java-common-[version].jar
│ │ ├── cometd-java-server-[version].jar
│ │ ├── jetty-continuation-[version].jar
│ │ ├── jetty-jmx-[version].jar
│ │ ├── jetty-servlets-[version].jar
│ │ └── jetty-util-[version].jar

It is not stated anywhere that the additional JARs like continuation,
util, etc., must be sourced from a Jetty7 distribution - that is not
at all clear. There are many places that say the CometD library is
equally compatible with Jetty6, Jetty7, and Jetty8. So, in a
situation where for Jetty6 we need to also obtain certain JARs from
Jetty7, it would be much simpler to explicitly state this - that would
have saved me a day of searching and posting.



Also, I'd like to ask your advice on an example implementation -

Our use case is this:
In our server-side service code, we have event listeners that detect
periodic updates to certain data.
Each time such a data update is received, we would like to push this
new data to the connected client.

So, I need to only publish data, from server to JavaScript client.
Can you direct me to a simple example that illustrates a simple case
like this? Most of the examples (like the one I've referenced in the
CometD book) show the use of services (which I interpret as server
listeners for client-generated events, which I don't need) and other
complexities that don't apply to my case. So, any suggestion you can
provide for a simplified example would be appreciated.

Thanks,
Don P.

[Simone Bordet]

Hi,

On Tue, May 22, 2012 at 4:47 PM, donp <don...@gmail.com> wrote:
> Simone,
>
> Thank you very much for your quick reply.
>
> I've updated my /lib area with the additional JAR files, and now the
> CometdServlet is loading as expected.  So, thanks for that.

Cool.

Mmm, ok.

However, even if you do not use Maven in your organization, you can
use it locally on your computer, build a skeleton project from the
archetype like said in the Maven way in the primer, and then use that
structure for your non-Maven project.
Total time, less than 20 seconds :)

> Also, I'd like to ask your advice on an example implementation -
>
> Our use case is this:
> In our server-side service code, we have event listeners that detect
> periodic updates to certain data.
> Each time such a data update is received, we would like to push this
> new data to the connected client.
>
> So, I need to only publish data, from server to JavaScript client.
> Can you direct me to a simple example that illustrates a simple case
> like this?  Most of the examples (like the one I've referenced in the
> CometD book) show the use of services (which I interpret as server
> listeners for client-generated events, which I don't need) and other
> complexities that don't apply to my case.  So, any suggestion you can
> provide for a simplified example would be appreciated.

Inherited CometD Services can be used both as receivers and as
senders, and it's my recommended way to go.

This thread should get you started:
https://groups.google.com/forum/?fromgroups#!topic/cometd-users/C5xa-zK1qQs.

Let us know if it worked.

[donp]

Hello Simone,

Thanks again for the reply.

The example I am looking for is really just a very simple example of
push from Java server to JavaScript client. The code in the post that
you replied with, looks like it is showing only Java server code, no
JavaScript client code.

The challenges I am running into are:

1. I have not seen any documentation of the JavaScript API at all.
There are only short snippets of code, but no API/JavaDoc
documentation.
2. All of the JavaScript code snippets assume the use of dojo or
jQuery. I am not using either (I am using GWT). There are no
snippets or examples that show the core JavaScript being used.
3. There are no simple examples for what seems like the most common
case, of what I described above - push from Java server to JavaScript
client.
4. The primer mentions a required JavaScript file, application.js.
but, there is nowhere that describes what this file is, and there is
no example of this file in the distribution. So, currently I do not
have a file like this in my application.

So, I am struggling hacking away with bits and pieces that I find, but
this is not very efficient or successful.

The most recent issue I've run into is, when I call
cometd.subscribed(channelName, callback) in my JavaScript, it is
throwing an exception:
Uncaught TypeError: Cannot call method 'getType' of null

The exception is caused by the second line below in cometd.js:
_transport = _transports.negotiateTransport(transportTypes,
version, _crossDomain, _config.url);
_cometd._debug('Initial transport is', _transport.getType());

because, _transport is null. In the first line, transportTypes is a
zero-length array.


Can you provide any more suggestions on any of the above issues?

Thanks,
Don P.

[Simone Bordet]

Hi,

On Tue, May 22, 2012 at 9:27 PM, donp <don...@gmail.com> wrote:
> Hello Simone,
>
> Thanks again for the reply.
>
> The example I am looking for is really just a very simple example of
> push from Java server to JavaScript client.  The code in the post that
> you replied with, looks like it is showing only Java server code, no
> JavaScript client code.
>
> The challenges I am running into are:
>
> 1. I have not seen any documentation of the JavaScript API at all.
> There are only short snippets of code, but no API/JavaDoc
> documentation.

http://docs.cometd.org/reference/#javascript

> 2. All of the JavaScript code snippets assume the use of dojo or
> jQuery.  I am not using either (I am using GWT).

https://github.com/belu/gwt-cometd

> There are no
> snippets or examples that show the core JavaScript being used.

That is because the core JavaScript library relies on toolkits to
provide transports.
See above the GWT bindings.

> 3. There are no simple examples for what seems like the most common
> case, of what I described above - push from Java server to JavaScript
> client.

This is done in the demos, and it's also shown in the reference documentation.

> 4. The primer mentions a required JavaScript file, application.js.
> but, there is nowhere that describes what this file is, and there is
> no example of this file in the distribution.  So, currently I do not
> have a file like this in my application.

I do not understand this question.
The file application.js is not required. It's how I decided to name
it, you can name it how you want.

> So, I am struggling hacking away with bits and pieces that I find, but
> this is not very efficient or successful.

Have you read the documentation ?
Have you studied the primer code ?

> The most recent issue I've run into is, when I call
> cometd.subscribed(channelName, callback) in my JavaScript, it is
> throwing an exception:
> Uncaught TypeError: Cannot call method 'getType' of null

There is a typo: it's not "subscribed" it's "subscribe".

> The exception is caused by the second line below in cometd.js:
>       _transport = _transports.negotiateTransport(transportTypes,
> version, _crossDomain, _config.url);
>       _cometd._debug('Initial transport is', _transport.getType());
>
> because, _transport is null.  In the first line, transportTypes is a
> zero-length array.

That is probably caused by how you use CometD with GWT.
See the link above for existing GWT bindings so you do not reinvent the wheel.

[donp]

Simone,

Thanks I will take a look at the gwt-cometd project.
Is this part of the main cometd project?
I'm asking about the licensing aspect. Cometd project is Apache2
license, and we intend to use this in a product which requires the
Apache2 license.

Thanks,
Don P.

[Simone Bordet]

Hi,

On Tue, May 22, 2012 at 9:48 PM, donp <don...@gmail.com> wrote:
> Simone,
>
> Thanks I will take a look at the gwt-cometd project.
> Is this part of the main cometd project?

No.

> I'm asking about the licensing aspect.  Cometd project is Apache2
> license, and we intend to use this in a product which requires the
> Apache2 license.

Don't know, ask the maintainer to be sure, but looks Apache 2 as well.

[Christian Kellner]

Hi there

We currently trying to find out how many user (long polling/websockets) a server can handle until messages will get lost.

We've installed 2 jettys with a small chat application installed on 1server. The both jettys communicate via oort.

We tried both, broadcast messages as well as direct messages via seti. When we tried to send 20.000 messages (20 clients a 100 messages) around 200 messages get lost. Even with pure websockets, we lost messages when we fire around 25.000 messages.

Does anyone of you have experience with Oort? Is this something which one can use for a real use case, means for a chat with around 100.000 users..?
We have to find out whether cometd is the right technology as well as how many server we would need to fit so many user..

Thx
Christian

[Simone Bordet]

Hi,

On Tue, May 22, 2012 at 11:07 PM, Christian Kellner
<chriz...@googlemail.com> wrote:
> Hi there
>
> We currently trying to find out how many user (long polling/websockets) a server can handle until messages will get lost.

http://webtide.intalio.com/2011/09/cometd-2-4-0-websocket-benchmarks/

> We've installed 2 jettys with a small chat application installed on 1server. The both jettys communicate via oort.
>
> We tried both, broadcast messages as well as direct messages via seti.
> When we tried to send 20.000 messages (20 clients a 100 messages) around 200 messages get lost.
> Even with pure websockets, we lost messages when we fire around 25.000 messages.

You need to be a lot more precise.
You say 20 clients 100 messages that makes 2k messages, not 20k.
What is the global message rate ?
How do you send the messages ?
Do you use the CometD load tools ?
How do you know it's not your client that looses messages ?

> Does anyone of you have experience with Oort? Is this something which one can use for a real use case, means for a chat with around 100.000 users..?
> We have to find out whether cometd is the right technology as well as how many server we would need to fit so many user..

With websocket, we have achieved 200k users at 20k messages/s, with 1
server only, and small latencies.

Note that tuning for large numbers can become quite tricky, because
you have to juggle several things together, but it's definitely
doable.

[donp]

Hi Simone -

I am now using the GWT bindings you referred me to, and am able to
handshake from teh GWT/Javascript client.

I have a very simplistic code setup now as I am still debugging/trying
to get a stable setup, so I am not yet even trying to send any
messages between server and client. After making the handshake, I am
now seeing an endless string of errors/exceptions in the Eclipse
console output, like below.

The code I have currently is this:

SERVER - (in GWT RemoteServiceServlet.init() )

// for CometD/Bayeux
if (bayeux == null) {
bayeux =
(BayeuxServer)getServletContext().getAttribute(BayeuxServer.ATTRIBUTE);
}

CLIENT - (in GWT view constructor)

// Set up a cometd/bayeux listener to listen for dashboard
events.
CometDConfiguration config = new CometDConfiguration("http://
127.0.0.1:8080/cometd");
config.setLogLevel(LogLevel.debug);
CometD cometd = new CometD(config);
cometd.handshake();

WEB.XML -

<servlet>
<servlet-name>cometd</servlet-name>
<servlet-class>org.cometd.server.CometdServlet</servlet-class>
<load-on-startup>1</load-on-startup>
<init-param>
<param-name>timeout</param-name>
<param-value>60000</param-value>
</init-param>
<init-param>
<param-name>logLevel</param-name>
<param-value>3</param-value>
</init-param>
</servlet>




I have no other cometd code in either the client or server, so I'm
confused about why anything would be happening after the handshake -
since I'm not explicitly publishing or subscribing anything.

I am using Jetty6, with the Jetty7 continuations.

The exceptions I'm seeing below happen after the handshake(),
immediately following the first client application request. After the
first request, there is a continuous stream of these exceptions.
After the CometdServlet starts, I do see this in the log:

5/23/12 10:51:37 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1395965500] Added channel /meta
5/23/12 10:51:37 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1395965500] Added channel /meta/handshake
5/23/12 10:51:37 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1395965500] Added channel /meta/connect
5/23/12 10:51:37 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1395965500] Added channel /meta/subscribe
5/23/12 10:51:37 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1395965500] Added channel /meta/unsubscribe
5/23/12 10:51:37 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1395965500] Added channel /meta/disconnect
5/23/12 10:51:37 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1395965500] Allowed Transports: [callback-polling, long-polling]


Can you give any explanation or suggestions about this? Let me know
if I can provide any other information.


Thanks again,
Don P.



EXCEPTIONS
----------

5/23/12 10:48:41 AM EDT [ERROR] [org.mortbay.log] /cometd/connect
java.lang.IllegalStateException: STREAM
at org.mortbay.jetty.Response.getWriter(Response.java:616)
at org.cometd.server.transport.JSONTransport.send(JSONTransport.java:
84)
at
org.cometd.server.transport.LongPollingTransport.handle(LongPollingTransport.java:
348)
at org.cometd.server.CometdServlet.service(CometdServlet.java:181)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:
511)
at org.mortbay.jetty.servlet.ServletHandler
$CachedChain.doFilter(ServletHandler.java:1221)
at
com.wily.webserver.filter.RequestLocaleFilter.doFilter(RequestLocaleFilter.java:
46)
at org.mortbay.jetty.servlet.ServletHandler
$CachedChain.doFilter(ServletHandler.java:1212)
at
com.wily.introscope.webapps.common.filter.WebViewSSOFilter.doFilter(WebViewSSOFilter.java:
105)
at org.mortbay.jetty.servlet.ServletHandler
$CachedChain.doFilter(ServletHandler.java:1212)
at
com.wily.introscope.webapps.common.filter.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:
151)
at org.mortbay.jetty.servlet.ServletHandler
$CachedChain.doFilter(ServletHandler.java:1212)
at com.wily.introscope.webview.server.IntroscopeWebView
$ConnectionFilter.doFilter(IntroscopeWebView.java:452)
at org.mortbay.jetty.servlet.ServletHandler
$CachedChain.doFilter(ServletHandler.java:1212)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:
399)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:
216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:
182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:
766)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:
450)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:
230)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:
152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:
542)
at org.mortbay.jetty.HttpConnection
$RequestHandler.content(HttpConnection.java:945)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.jetty.bio.SocketConnector
$Connection.run(SocketConnector.java:228)
at org.mortbay.thread.BoundedThreadPool
$PoolThread.run(BoundedThreadPool.java:451)
5/23/12 10:48:41 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1165666909] > {id=14873, connectionType=long-polling,
advice={timeout=0}, channel=/meta/connect,
clientId=2p3s016299vb9fnmvpkv4qzid} 2p3s016299vb9fnmvpkv4qzid - last
connect 0 ms ago
5/23/12 10:48:41 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1165666909] >> {id=14873, connectionType=long-polling,
advice={timeout=0}, channel=/meta/connect,
clientId=2p3s016299vb9fnmvpkv4qzid}
5/23/12 10:48:41 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1165666909] << {id=14873, successful=true, advice={interval=0,
reconnect=retry, timeout=60000}, channel=/meta/connect}
5/23/12 10:48:41 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1165666909] < {id=14873, successful=true, advice={interval=0,
reconnect=retry, timeout=60000}, channel=/meta/connect}
5/23/12 10:48:41 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1165666909] > {id=14874, connectionType=long-polling, channel=/meta/
connect, clientId=2p3s016299vb9fnmvpkv4qzid} 2p3s016299vb9fnmvpkv4qzid
- last connect 0 ms ago
5/23/12 10:48:41 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1165666909] >> {id=14874, connectionType=long-polling, channel=/meta/
connect, clientId=2p3s016299vb9fnmvpkv4qzid}
5/23/12 10:48:41 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1165666909] << {id=14874, successful=true, channel=/meta/connect}
5/23/12 10:48:41 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1165666909] > {id=14875, connectionType=long-polling,
advice={timeout=0}, channel=/meta/connect,
clientId=2p3s016299vb9fnmvpkv4qzid} 2p3s016299vb9fnmvpkv4qzid - last
connect 0 ms ago
5/23/12 10:48:41 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1165666909] >> {id=14875, connectionType=long-polling,
advice={timeout=0}, channel=/meta/connect,
clientId=2p3s016299vb9fnmvpkv4qzid}
5/23/12 10:48:41 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1165666909] << {id=14875, successful=true, advice={interval=0,
reconnect=retry, timeout=60000}, channel=/meta/connect}
5/23/12 10:48:41 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
1165666909] < {id=14875, successful=true, advice={interval=0,
reconnect=retry, timeout=60000}, channel=/meta/connect}

----------

[Simone Bordet]

Hi,

On Wed, May 23, 2012 at 4:56 PM, donp <don...@gmail.com> wrote:
> After the CometdServlet starts, I do see this in the log:
>
> 5/23/12 10:51:37 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
> 1395965500] Added channel /meta
> 5/23/12 10:51:37 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
> 1395965500] Added channel /meta/handshake
> 5/23/12 10:51:37 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
> 1395965500] Added channel /meta/connect
> 5/23/12 10:51:37 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
> 1395965500] Added channel /meta/subscribe
> 5/23/12 10:51:37 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
> 1395965500] Added channel /meta/unsubscribe
> 5/23/12 10:51:37 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
> 1395965500] Added channel /meta/disconnect
> 5/23/12 10:51:37 AM EDT [INFO] [org.cometd.server.BayeuxServerImpl.
> 1395965500] Allowed Transports: [callback-polling, long-polling]

That's normal operations. The server created the meta channels.

> EXCEPTIONS
> ----------
>
> 5/23/12 10:48:41 AM EDT [ERROR] [org.mortbay.log] /cometd/connect
> java.lang.IllegalStateException: STREAM
>        at org.mortbay.jetty.Response.getWriter(Response.java:616)
>        at org.cometd.server.transport.JSONTransport.send(JSONTransport.java:
> 84)
>        at
> org.cometd.server.transport.LongPollingTransport.handle(LongPollingTransport.java:
> 348)
>        at org.cometd.server.CometdServlet.service(CometdServlet.java:181)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>        at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:
> 511)
>        at org.mortbay.jetty.servlet.ServletHandler
> $CachedChain.doFilter(ServletHandler.java:1221)
>        at
> com.wily.webserver.filter.RequestLocaleFilter.doFilter(RequestLocaleFilter.java:
> 46)
>        at org.mortbay.jetty.servlet.ServletHandler
> $CachedChain.doFilter(ServletHandler.java:1212)
>        at
> com.wily.introscope.webapps.common.filter.WebViewSSOFilter.doFilter(WebViewSSOFilter.java:
> 105)

You have a bunch of com.wily.introscope.* filters in the middle that
are not behaving well.
In particular, they get the response OutputStream when they should not
(without wrapping the response).
When CometD wants to take the Writer, it throws an
IllegalStateException as per the Servlet specification.
Remove those filters.

I also can't see that you're using the ContinuationFilter.

I really recommend that you build your application starting from the
Maven archetypes that are described in the primer.
There are archetypes for Jetty 6 that will set you up accordingly.
Once you have done that, you have the correct config and you can start
building on top.

Doing otherwise will just waste your time because you will encounter a
number of problems that are already solved by the archetypes.

>        at org.mortbay.jetty.bio.SocketConnector

You should be using the SelectChannelConnector when you use the
continuations because it scales better.

[donp]

Hi Simon,

Thanks as always for your quick reply.

I was initially using the ContinuationFilter, but then removed this
because I saw something in the documentation that stated it was not
necessary if using a Jetty servlet container. If you say it is
necessary, then I will put it back.

Regarding Maven -

I have used Maven once, simply for downloading repository artifacts
for a project that I could not obtain in any other way. In that case,
all I need was the artifacts themselves, and I had no other need for
Maven. As I mentioned before (and I am not alone in this, based on
the other poster that I quoted above), I am simply not willing to
invest time in setting up and learning about Maven, and going through
Maven build processes, in order to use any project, including this
one. It seems unnecessary to force potential users to go through
this, when I assume that the archetypes you're referring to are simply
static code with different variations - which could be provided as
built JARs. Providing a built JAR is a fairly standard way of
distributing a project like this.

I already had a working setup with a different comet-like library,
which works with GWT, and which was working in my application - it
took me a half-day to get that fully working in my application. I
thought it would make sense to look into cometd, since it seemed to be
slightly more standards-based. However, the requirement to build
static artifacts like this and the overhead involved seems a bit more
than many users will want to get involved in, who are not currently
using Maven. With this, I am on my third day of trying to get Cometd
working, with no success yet.

I understand the benefits of Maven, but there is no guarantee that
every potential user of the Cometd library either already uses it, or
is willing to adopt it simply to gain access to this library. If the
Cometd project is not willing to be flexible in this area, the pool of
potential users may likely be smaller because of this.

Sorry for the long response, but the effort here on my end is getting
larger every day, and it looks like part of this is a result of the
lack of pre-built, easily integrated artifacts being provided. Having
those available would minimize the time and frustration of users, and
would also very likely minimize the time you would spend answering
queries like mine ;-/

If you can provide any other guidance for a "non-Maven" approach,
please let me know.

Thanks,
Don P.

[donp]

Simone,

This is the documentation that caused me to remove ContinuationFilter
-

----------
http://cometd.org/node/128
The CometD implementation relies on Jetty Continuations.
This exception is thrown by the Jetty Continuation library when it
finds that the web application configuration is not correct for the
library to work.

To run properly, web applications that make use of this library needs
either:

to run inside Jetty 6 or Jetty 7
to run in a Servlet 3.0 compliant servlet container
to have the ContinuationFilter configured properly
----------

This is suggesting that running in a Jetty 6 container does not
require ContinuationFilter. I am using Continuations running in a
Jetty 6 container.

Thanks,
Don P.

[Simone Bordet]

Hi,

On Wed, May 23, 2012 at 5:24 PM, donp <don...@gmail.com> wrote:
> Regarding Maven -

[snip]

I have not explained myself correctly.

I am not saying that you must use Maven for your project.

I am saying that you should use it to create a local prototype,
proof-of-concept, spike, call it how you like it, that will get you
started.

Complaining about Maven archetypes it's like complaining about Rails
scaffolding: they do exacly the same thing, yet noone complains about
Rails scaffolding.
Maven archetypes build a prototype. Once done, uninstall Maven if you
do not like it, but Maven would have saved you 3 days and presented
you with a proper configuration for Jetty 6 in probably 10 minutes.

As for providing a zip for a skeleton project, we're working on
tutorials and you may get that, we'll see.