Is there a standard way to notify cometd subscriber than the channel data is currently unavailable?
j
data is currently unavailable?
For example, say we have a chat service. My server encountered a
connection problem with the backend chat service (say gtalk), is there
a standard way to let the subscriber know the service is unavailable?
Simone Bordet
Not that I know of.
The usual HTTP errors for this condition are 502 or 504, you may want
to return that code embedded in a comet response to the client.
Simon
--
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
neek
seems pretty straightforward. I see that in the dojox client
implementation, longPollTransportJsonEncoded.js's sendMessage()
function uses the rawXhrPost's error callback to call
cometd._publishMeta, which causes the cometd code to publish to the
dojo channel with:
dojo.publish(this.prefix + "/meta", [meta]);
The meta information includes an action="publish" and
successful=false.
Thus, if you have connection.subscribed()'d to a channel called "/
foo", and try to post a message which fails because the remote server
is down, you can dojo.subscribe("/foo/meta") and get a notification of
the fact.
Similarly, the longPollTransportJsonEncoded method openTunnelWith()
sets up an error handler on the connection which will publish on the
dojo channel "/foo/meta" with an action="connect" and
successful=false. This seems to be the hook for notifications of when
a service becomes unavailable.
Does that help?
Nick
j
client.
Simone Bordet
On Thu, Jun 25, 2009 at 05:35, neek<neekf...@gmail.com> wrote:
>
> I use the dojo 1.3.1 client implementation in dojox.cometd, and it
> seems pretty straightforward. I see that in the dojox client
> implementation, longPollTransportJsonEncoded.js's sendMessage()
> function uses the rawXhrPost's error callback to call
> cometd._publishMeta, which causes the cometd code to publish to the
> dojo channel with:
>
> dojo.publish(this.prefix + "/meta", [meta]);
>
> The meta information includes an action="publish" and
> successful=false.
>
> Thus, if you have connection.subscribed()'d to a channel called "/
> foo", and try to post a message which fails because the remote server
> is down, you can dojo.subscribe("/foo/meta") and get a notification of
> the fact.
>
> Similarly, the longPollTransportJsonEncoded method openTunnelWith()
> sets up an error handler on the connection which will publish on the
> dojo channel "/foo/meta" with an action="connect" and
> successful=false. This seems to be the hook for notifications of when
> a service becomes unavailable.
>
> Does that help?
Just bear in mind that that way of doing things will be different when
dojo merges in the latest cometd code.
Greg's working on a compatibility layer, but not sure what extent it will have.
If you start an app from scratch, it's better to start with the new code.
Cheers,
j
The new cometd is different from old cometd in what ways? Can you
share some insights?
Yes I am starting an app from scratch.
Simone Bordet
On Thu, Jun 25, 2009 at 20:11, j<jac...@gmail.com> wrote:
>
> Hi Simone,
>
> The new cometd is different from old cometd in what ways? Can you
> share some insights?
>
> Yes I am starting an app from scratch.
The basic API is quite similar, if not identical.
Changes are in:
1. extension registration, now a full blown API with callbacks from
comet to extension,
2. in the initialization, now split in 2 methods to allow reconfiguration,
3. in the meta channels and how meta messages are delivered, now not
anymore based on toolkit event system (to achieve portability) and
with a global channel for failures
4. some facility like reestablish is gone (not sure about this)
5. enhanced logging
6. better configuration for reconnections
7. better handling of the 2 connection limit, also configurable,
8. cleaner code and code documentation.
What's missing is the cometd.org documentation, but I am working on
it, with examples, gotchas, etc.
I don't mind native english speaker review, or even better documentation help.
Cheers,
Simon
--
neek
beta10 cometd working in Glassfish with the ContinuationFilter. I see
that the new org.cometd code no longer uses dojo.publish() to tell
subscribers about important events, as I said in a previous post.
On Jun 26, 1:23 am, Simone Bordet <simone.bor...@gmail.com> wrote:
> 3. in the meta channels and how meta messages are delivered, now not
> anymore based on toolkit event system (to achieve portability) and
> with a global channel for failures
subscribe to meta events on my connection, but I get no event for
server disconnection (e.g. my Jetty server is stopped.. the client
gets no event that I can see):
dojox.cometd.init({url:"/MyApp/cometd", logLevel: 'debug'});
dojox.cometd.subscribe("/meta/*", function(data) {
console.log("META: ", data);
});
I get lots of meta events for handshaking, connecting etc. but no
disconnect event.
I find that dojox.cometd.getStatus() always returned "connected", even
if Jetty has been shut down.
Perhaps there are some docs that cover the new API and how to see
these events?
Assistance would be greatly appreciated :) My app used to cleanly
handle the web server being restarted, but now I need to restart my
web app to make it re-subscribe to the channels it's interested in :(
Nick
Jan Bartel
You need to use dojox.cometd.addListener() for the meta channels,
not dojox.cometd.subscribe().
This is explained in the doco here: http://cometdproject.dojotoolkit.org/documentation/cometd-javascript/subscription
The doco also shows you how to listen on /meta/connect to find out
the connection status.
cheers
Jan
neek
> You need to use dojox.cometd.addListener() for the meta channels,
> not dojox.cometd.subscribe().
("/meta/*" ....), and still find no disconnect event is fired.
The beta10 source in org/cometd/cometd.js seems to show subscribe()
simply calling _addListener(), with a little extra housekeeping to do
with publishing a /meta/subscribe message about the new subscription.
I appreciate the effort made in the docs to theologically separate
subscribe() and addListener(), but am not sure there's much difference
in their implementation.
From my debugging of the longPollTransport stuff (the tunnelCollapse()
method never seems to be fired for me) I'm driving toward the
conclusion that there is no long standing network connection made by
the new cometd code that would be broken by Jetty shutting down. I'm
unfamiliar with the latest Firebug gui, but cannot see any open
connections after my test webpage has initialised its cometd
connection. Thus, no error callback is fired when I shut down Jetty,
so no attempt is made by cometd to notify my app, either as a
subscriber or listener, about the drop in connection. This is also
why getStatus() always returned "connected".
Just to be clear, all my debugging shows that my test app handshakes,
connects, gets /meta/* events, and publishes/receives messages on my
channel just fine. However, when I shut down Jetty, absolutely no
further events happen on the client. The last thing I see is usually
a "chat received!" message indicating the last publish/subscribe event
worked.
> This is explained in the doco here:http://cometdproject.dojotoolkit.org/documentation/cometd-javascript/...
Thank you. I had wandered into http://cometd.org and found some of
that documentation, but since I had working subscriptions to the meta
channels and debugged the code a fair bit, I had a feeling I was
beyond the documentations ability to guide me.
> The doco also shows you how to listen on /meta/connect to find out
> the connection status.
server has shut down (and I've waited some 5 minutes or more to allow
a network timeout to happen) there must be some more serious
underlying fault that would trip up even the /meta/connect system.
I'm running Jetty 6.1.19 with cometd beta10 (client javascript and
servlet) on Firefox 3.5.2.
Cheers
Nick
Simone Bordet
On Thu, Aug 6, 2009 at 09:43, neek<neekf...@gmail.com> wrote:
>
> On Aug 6, 2:08 pm, Jan Bartel <j...@mortbay.com> wrote:
>> You need to use dojox.cometd.addListener() for the meta channels,
>> not dojox.cometd.subscribe().
>
> Thanks for the response. I get very similar behaviour with addListener
> ("/meta/*" ....), and still find no disconnect event is fired.
>
> The beta10 source in org/cometd/cometd.js seems to show subscribe()
> simply calling _addListener(), with a little extra housekeeping to do
> with publishing a /meta/subscribe message about the new subscription.
> I appreciate the effort made in the docs to theologically separate
> subscribe() and addListener(), but am not sure there's much difference
> in their implementation.
I am not sure what you mean here.
There is a big difference in that if you don't call subscribe(), any
server-side event you're interested to will not be delivered to you,
no matter if you called addListener().
> From my debugging of the longPollTransport stuff (the tunnelCollapse()
> method never seems to be fired for me) I'm driving toward the
> conclusion that there is no long standing network connection made by
> the new cometd code that would be broken by Jetty shutting down.
If you are looking at tunnelCollapse() then you're looking at a very
old version of Cometd; you should look at the new implementation,
which you seem to have looked to when you were talking about
subscribe.
> I'm unfamiliar with the latest Firebug gui, but cannot see any open
> connections after my test webpage has initialised its cometd
> connection. Thus, no error callback is fired when I shut down Jetty,
> so no attempt is made by cometd to notify my app, either as a
> subscriber or listener, about the drop in connection. This is also
> why getStatus() always returned "connected".
Are you doing cross-domain communication ?
If that's the case, then logging and notification of failures are much
reduced due to the way the transport implements the cross-domain
communication.
> Just to be clear, all my debugging shows that my test app handshakes,
> connects, gets /meta/* events, and publishes/receives messages on my
> channel just fine. However, when I shut down Jetty, absolutely no
> further events happen on the client. The last thing I see is usually
> a "chat received!" message indicating the last publish/subscribe event
> worked.
>
>> This is explained in the doco here:http://cometdproject.dojotoolkit.org/documentation/cometd-javascript/...
>
> Thank you. I had wandered into http://cometd.org and found some of
> that documentation, but since I had working subscriptions to the meta
> channels and debugged the code a fair bit, I had a feeling I was
> beyond the documentations ability to guide me.
>
>> The doco also shows you how to listen on /meta/connect to find out
>> the connection status.
>
> I presume that if getStatus() returns "connected" even when the remote
> server has shut down (and I've waited some 5 minutes or more to allow
> a network timeout to happen) there must be some more serious
> underlying fault that would trip up even the /meta/connect system.
This could happen with cross-domain transport. We have to improve
failure notification for that.
neek
> I am not sure what you mean here.
> There is a big difference in that if you don't call subscribe(), any
> server-side event you're interested to will not be delivered to you,
> no matter if you called addListener().
so what I said was not correct in the overall sense. I've had better
results in the last few days and am now using addListener() as I
should.
> > From my debugging of the longPollTransport stuff (the tunnelCollapse()
> > method never seems to be fired for me) I'm driving toward the
> old version of Cometd; you should look at the new implementation,
> which you seem to have looked to when you were talking about
> subscribe.
client source (the new dojox/cometd.js, dojox/cometd/*, org/cometd.js,
org/cometd/*) and bring it into my project, which was based on dojo
1.3.1. I made various mistakes, and had left some of the old dojo
implementation in place, which just confused me. I realised that the
org/cometd.js now includes the LongPollingTransport impl, which is
much simplified.
> Are you doing cross-domain communication ?
Now that I think I've cleaned out the old dojo cometd client
implementation and inserted the new files from the beta10 tarball, I'm
getting better results. I've wasted quite some time using the files
from cometd-javascript/dojo/target/war/work/org.dojotoolkit/dojo-war/
dojox before I realised these look like the old dojo implementation.
With no guidance, I had just used a 'find' command to locate the files
I was after.
Have I missed some instructions that say exactly what parts of the
beta10 tarball one should take to form a set of working client files?
I'm no good with Maven, and browsing pom.xml files just makes my head
hurt. So far, I'm using:
dojox/cometd.js and dojox/cometd/* from:
cometd-1.0.beta10/cometd-javascript/dojo/src/main/webapp
org/cometd.js and org/cometd/* from:
cometd-1.0.beta10/cometd-javascript/common/src/main/webapp
My latest results are intermittent, but this seems to be because I'm
using jetty 6 as my container, and the beta10 mvn build builds against
your shipped jetty 7 M4 jars, right? I'm guessing the resultant
cometd jars, which I've copied into my jetty 6 lib directory, are not
stable to run with the rest of the jetty infrastructure.
Jetty doesn't seem to report exceptions reliably... I found one
attempt failed silently and turning on DEBUG logging in Jetty showed
me it had tried to classload a commons collections class. I'd
forgotten to include the commons-collections.jar file in my app's WEB-
INF/lib. Putting it in got me a step further. Such lack of
ClassNotFoundExceptions makes me extremely uncertain of my
platform! :)
So, I'm trying to switch to Jetty 7, however I find the Jetty download
pages (between jetty.mortbay.org and http://www.eclipse.org/jetty/downloads.php)
don't actually seem to offer a jetty 7 download. They lead you round
in circles, and the update site at http://download.eclipse.org/jetty/stable-7/update/
is 'under construction'. Huh. I have a jetty 7 RC1 that I downloaded
a while back, so I'm not sure if I should go with that, or the jars
shipped in your beta 10 release.
I really admire the cometd project, and I know it's the way forward,
shame I'm having so much trouble using it :)
Simone Bordet
On Tue, Aug 11, 2009 at 04:56, neek<neekf...@gmail.com> wrote:
>> Are you doing cross-domain communication ?
>
> I'm doing everything on localhost, so no cross-domain that I know of.
Well not exactly.
If you load the JS files from "localhost" but then specify the URL of
the Bayeux server as "127.0.0.1", then that's treated as cross-domain.
As for your troubles setting up a project, there is a primer you can
follow here: http://cometdproject.dojotoolkit.org/documentation/primer
The primer explains (or should do that ;) how to setup a basic
skeleton for your project.
I'd appreciate feedback, as I may have overlooked some important parts.
If you use Maven, it is as simple as (after building cometd):
$ mvn archetype:generate -DarchetypeCatalog=local
and then follow the instructions.
This will correctly create a war structure that contains the correct
files for both dojo, jquery, jetty6, jetty7 and any combination
thereof.
Let us know how goes with the primer.
neek
> > I'm doing everything on localhost, so no cross-domain that I know of.
>
> Well not exactly.
> If you load the JS files from "localhost" but then specify the URL of
> the Bayeux server as "127.0.0.1", then that's treated as cross-domain.
URI's relative to that. I see the difference between that and
127.0.0.1.
> As for your troubles setting up a project, there is a primer you can
> follow here:http://cometdproject.dojotoolkit.org/documentation/primer
the cometd.org documentation pages and the beta10 drop (actually beta8
a while back with similarly distressing results) and figured out much
of that primer the hard way. I think my biggest mistake was trying to
use jetty 6. I did this mainly because I could only find an Eclipse
server adapter for Jetty 6, and I figured the change in namespace for
so many Jetty classes would mean I could run the Jetty 6
infrastructure in the same VM as the org.cometd cometd servlet and
related Jetty 7 .jar's. This appears to be impossible, and results in
no useful exceptions being thrown to tell you you're attempting the
impossible.
I was coming from Glassfish, and the live code replacement features
available in its server adapter make developing a dynamic web
application a breeze. In comparison, I'm now stuck with Jetty 7, with
no server adapter, a manually created build.xml to build my .war file,
and a jetty context xml file for hot deployment that still seems to
need me to stop and restart jetty when I change my javascript files.
Development is much (much much) more annoying than with Glassfish.
Trying to run in Jetty 6, with cometd beta10 jars built against your
shipped jetty 7 jars, I think resulted in some really fatal silent
failures. I can't explain it, things simply didn't work. The client
managed to handshake and do initial connect, and the server threw no
exceptions. Sometimes /meta/connect attempts from the javascript
would result in "200 OK" yet "Content-Length: 0" responses from the
cometd servlet. Really frustrating. I also tried about 6 different
releases of Glassfish, and also spent a lot of time trying to use the
Grizzly cometd servlet against the org.cometd beta8 javascript client,
with no luck.
But today .. joy of joys .. success!
With the cometd beta10 jars (built from the mvn build of the beta10
tarball) running on jetty 7 RC2 and a dojo source tree much like that
described in the primer you linked to, my app is now running quite
well. Of course I had to update my javascript to use the new
org.cometd javascript syntax, which was easy once I had a stable
jetty.
> The primer explains (or should do that ;) how to setup a basic
> skeleton for your project.
> I'd appreciate feedback, as I may have overlooked some important parts.
- I do not want to use Maven at all. Figuring out deployment from the
36 pom.xml files included in the beta10 drop, when you've never used
Maven before, is no fun. I understand that you're using Maven as your
build tool, but please don't tie an understanding of the .war
directory structure to an understanding of the build tool. Rather,
explain the required directory structure (e.g. how to replace the
dojox/* and org/* .js files), and then perhaps explain how that is
achieved using your favourite tool.
- I would like to run in Glassfish, but had no luck at all getting it
to work (I think I posted here about the ContinuationFilter not
appearing to work). I have had to move entirely to Jetty from
Glassfish in order to use beta10, a move I will now probably try to
undo, all of which has resulted in days and days of effort. Perhaps
an Eclipse jetty 7 server adapter, that allows an Eclipse project to
be easily developed alongside a deployment of the same application in
Jetty, would really help. I can't find one.
- If it is really impossible to run beta10 (or whatever version) in
Jetty 6, please make that clear. I found the Jetty docs quite
frustrating, often talking about only Jetty 6 (because 7 is so new,
apparently), and many might try 6 by default, as I did. It's a long
and painful road to a dead end.
- It might be worth mentioning which parts of the web.xml need
replacing (under your "The Non-Maven Way" heading). I believe only
the 'cometd' servlet needs configuring, with the optional
ContinuationFilter for non-Jetty containers. As a side note, the
web.xml has nothing to do with Maven.
> If you use Maven, it is as simple as (after building cometd):
told to run a one-liner Maven command is extremely frustrating, and
causes me to completely ignore it and try to do everything by hand
with no instructions.
> Let us know how goes with the primer.
it.
Many thanks for the help. I look forward to getting my full app's
functionality restored (I was using beta7, before the big overhaul.
It ran in glassfish with jetty 6 support jars, but did generate a
number of IO exceptions while flushing servlet comms channels after
each comet message).
Nick
Simone Bordet
On Tue, Aug 11, 2009 at 15:38, neek<neekf...@gmail.com> wrote:
> I was coming from Glassfish, and the live code replacement features
> available in its server adapter make developing a dynamic web
> application a breeze. In comparison, I'm now stuck with Jetty 7, with
> no server adapter, a manually created build.xml to build my .war file,
> and a jetty context xml file for hot deployment that still seems to
> need me to stop and restart jetty when I change my javascript files.
> Development is much (much much) more annoying than with Glassfish.
Well, Jetty supports a development mode using the Maven plugin.
I read you're not a Maven fan, but nowadays IDEs supports well Maven.
> But today .. joy of joys .. success!
Good you finally made it.
>> The primer explains (or should do that ;) how to setup a basic
>> skeleton for your project.
>> I'd appreciate feedback, as I may have overlooked some important parts.
>
> Everyone's different. My response to your primer is:
>
> - I do not want to use Maven at all.
Fine.
> Figuring out deployment from the
> 36 pom.xml files included in the beta10 drop, when you've never used
> Maven before, is no fun. I understand that you're using Maven as your
> build tool, but please don't tie an understanding of the .war
> directory structure to an understanding of the build tool. Rather,
> explain the required directory structure (e.g. how to replace the
> dojox/* and org/* .js files), and then perhaps explain how that is
> achieved using your favourite tool.
I think this is explained in the "non maven way" section, but from
your comment I don't understand if that section does not explain well
enough.
Can you be more precise on what can be improved in the "non maven way" section ?
> - I would like to run in Glassfish, but had no luck at all getting it
> to work (I think I posted here about the ContinuationFilter not
> appearing to work).
Sorry have no experience using GF, so I cannot help here.
> - If it is really impossible to run beta10 (or whatever version) in
> Jetty 6, please make that clear.
Mmm, it's not, unless I miss something obvious.
> I found the Jetty docs quite
> frustrating, often talking about only Jetty 6 (because 7 is so new,
> apparently), and many might try 6 by default, as I did. It's a long
> and painful road to a dead end.
Can you pinpoint where that is ? I'll try to be clearer.
> - It might be worth mentioning which parts of the web.xml need
> replacing (under your "The Non-Maven Way" heading). I believe only
> the 'cometd' servlet needs configuring, with the optional
> ContinuationFilter for non-Jetty containers.
Ok, we need a section for non Jetty servlet containers.
We're open to contribution though :)
> As a side note, the
> web.xml has nothing to do with Maven.
Of course.
>> If you use Maven, it is as simple as (after building cometd):
>
> Again.. I have an existing project that does not use Maven. Being
> told to run a one-liner Maven command is extremely frustrating, and
> causes me to completely ignore it and try to do everything by hand
> with no instructions.
Ok, but is not the "non maven way" enough ?
It explains what to do to get the correct war structure, and from
there use the tool you want: Ant, IDE, whatever.
Maybe I am missing something ?
>> Let us know how goes with the primer.
>
> It looks very useful. Is it linked to from cometd.org? I didn't find
> it.
It's the first link of the "Books" section on the left of the
Documentation page: http://cometdproject.dojotoolkit.org/documentation
Cheers,
Ats
I'm sorry, if following might look too much as a commercial, but i
feel i have to comment on a post to this thread:
On Aug 11, 4:38 pm, neek <neekfenw...@gmail.com> wrote:
> I was coming from Glassfish, and the live code replacement features
> available in its server adapter make developing a dynamic web
> application a breeze. In comparison, I'm now stuck with Jetty 7, with
> no server adapter, a manually created build.xml to build my .war file,
> and a jetty context xml file for hot deployment that still seems to
> need me to stop and restart jetty when I change my javascript files.
> Development is much (much much) more annoying than with Glassfish.
actually it is just an automatic redeploy as far as i'm concerned. I
don't know what in-built code replacement features Glassfish has, but
i have been using JavaRebel for 2 years (mostly on Weblogic, but works
on almost any web/ejb containers) and unlike with jetty automatic
redeploy i never loose session or anything else held in memory of my
webapps. And it doesn't even take a second to replace existing java
code or static resources with changes.
Check out feature comparison with JVM HotSwap and get 30 days full
trial: http://www.zeroturnaround.com/javarebel/comparison/
and easy installation instructions that should get you started if you
are interested: http://www.zeroturnaround.com/javarebel/installation/
Ats
Greg Wilkins
neek,
So I hear your frustration that your "existing project that
does not use Maven" and that you "look forward to getting my
full app's functionality restored".
I'd like to remind you that we are not yet released a 1.0 and
are still finishing a significant refactor to separate cometd.org
out from jetty and to make it portable across servlet-3.0
webcontainers - while servlet-3.0 is also still not finalized
and a moving target.
If you want stability, the version bundled with the stable
jetty-6 releases is stable.
You are on the bleeding edge when using the latest version
and some breakages are to be expected.
So sorry for disruptions, breakages and documentation that is
not up to date. I do believe things are stabilizing and the
documentation is already much improved.
cheers
neek
> Well, Jetty supports a development mode using the Maven plugin.
> I read you're not a Maven fan, but nowadays IDEs supports well Maven.
"getting the project via Maven is easy, do it the normal way" which is
no help :) I'm sure there is a walkthrough somewhere I've missed.
> I think this is explained in the "non maven way" section, but from
> your comment I don't understand if that section does not explain well
> enough.
> Can you be more precise on what can be improved in the "non maven way" section ?
section is good, but it's frustrating that 'the maven way' takes
precedence. I guess I just don't like the full automation of the
maven way, because it hides so much detail. I'm used to thinking of
my web container, project source tree, third party libraries, build
process, and .war structure as independent things, and 'mvn install
jetty:run' leaves a lot to be discovered. I wouldn't say that at the
end of 'the maven way' section you can say "You have already written
your first Cometd application".
> > - If it is really impossible to run beta10 (or whatever version) in
> > Jetty 6, please make that clear.
>
> Mmm, it's not, unless I miss something obvious.
there is a Jetty 6 build option. It seems my previous attempt to
build the beta10 release following the README.txt in its root (which
say to run "mvn jetty:run") and take the built cometd .jar files into
Jetty 6 were doomed to failure.
> > I found the Jetty docs quite
> > frustrating, often talking about only Jetty 6 (because 7 is so new,
> > apparently), and many might try 6 by default, as I did. It's a long
> > and painful road to a dead end.
>
> Can you pinpoint where that is ? I'll try to be clearer.
when setting up Jetty 7 for the first time, the Jetty JNDI docs at
http://docs.codehaus.org/display/JETTY/JNDI don't mention which Jetty
version they are for, and I went round in circles for a while. I
finally have my Datasource working via Hibernate in Jetty 7. As Greg
W pointed out, I'm on the bleeding edge, and am not surprised things
are not well documented, but of course we should not be surprised that
this expected level of documentation causes an expected level of
frustration.
> > - It might be worth mentioning which parts of the web.xml need
> > replacing (under your "The Non-Maven Way" heading). I believe only
> > the 'cometd' servlet needs configuring, with the optional
> > ContinuationFilter for non-Jetty containers.
>
> Ok, we need a section for non Jetty servlet containers.
> We're open to contribution though :)
to GF, though, and if I understood what you're doing with the
ContinuationFilter I might be able to contribute. I have tried many
different drops of GF (both v3 prelude and v3 preview, about 10
different drops in total, and setting all that up and testing is a
right pain), both testing cometd and their own Grizzly cometd
implementation. I got servlet errors, as if the cometd servlet didn't
see the ContinuationFilter, in all of them, despite logging showing
the filter class being loaded.
> > As a side note, the
> > web.xml has nothing to do with Maven.
>
> Of course.
shouldn't be lumped in with the docs for another. As I skip over the
Maven section, I may miss fundamental instructions for my web.xml
config. I know you're in a difficult position, e.g. the primer is
Dojo-centric which probably annoys jQuery users. Lucky for me, I use
dojo.
> >> If you use Maven, it is as simple as (after building cometd):
>
> > Again.. I have an existing project that does not use Maven. Being
> > told to run a one-liner Maven command is extremely frustrating, and
> > causes me to completely ignore it and try to do everything by hand
> > with no instructions.
>
> Ok, but is not the "non maven way" enough ?
> It explains what to do to get the correct war structure, and from
> there use the tool you want: Ant, IDE, whatever.
> Maybe I am missing something ?
attention. I see it is indeed linked from http://cometd.org's
Documentation page, sorry if I made it sound like it wasn't.
> >> Let us know how goes with the primer.
> > It looks very useful. Is it linked to from cometd.org? I didn't find
> > it.
> It's the first link of the "Books" section on the left of the
> Documentation page:http://cometdproject.dojotoolkit.org/documentation
operated fine, though spitting many exceptions when running in
Glassfish), I pretty much ignored the primer when looking at beta10.
In trying to get beta10 to work from scratch, I went to cometd.org,
got the tarball from the Downloads, saw that the Documentation section
didn't seem to offer much advice (the 'Building' page just says 'run
maven') and so went my own way.
Greg mentioned Jetty 6 including a stable release of the cometd
implementation. I actually found it unusable (porting my Glassfish
based cometd beta7 app into Jetty 6 for the first time), and spent
quite some time trying to debug the client side to figure out what was
going on. I think my simple test client issued endless /meta/
connect's as soon as it tried to connect despite the server responding
'successful: true'), using the dojo 1.3.1 client js. This endless
stream was quite hard to interpret (I've since found the 'pause'
button on Firebug's Net panel which really helps) but I wasn't sure if
the client or servlet was going wrong. I didn't know enough to post a
reasonable report here, and had clearly made some mistake in my local
setup that I didn't want to bring it to the forum and ask you guys to
fix my mistakes, so gave up.
I hope my criticisms remain useful :)
Nick