Hi,
I think anything less than v 1.0 will not work. Maybe v.9 but it's
such a pain figuring out which version will work since they changed
the API from v .4 to v.9 and they always change the distro folder
layout/naming. Perhaps you should update the Bayeux blog example due
to the changes.
Or maybe the community should create a bundle with some working
examples since all internet examples seem to be using a specific Jetty
bundle. We'll be doing that as part of our commercial Web 2.0 tools in
our next release in any event.
Here's what should work on the latest dojo v 1.0.2 and the latest
Grizzly 1.7.x:
<script type="text/javascript" src="dojo-release-1.0.2/dojo/
dojo.js"></script>
...
dojo.require("dojox.cometd"); // layout change
// cometd.init({}, "/cometd/cometd"); API change... this does not work
dojox.cometd.init(serverURL); // API change... this works
dojox.cometd.subscribe('/channel1',
function(msg) {
console.log (msg.data); // FireBug logging
}
);
...
The other problem is "infinite Bayeux handshakes" on local host. It
seems that some combination of using localhost or 127.0.0.1 in the
AJAX code can cause these handshakes. This might be exclusive to Java
on Leopard or not but I'll post my finding in a subsequent email.
With respect to an embedded Grizzly, the CometdAdapter specifies the
context path of /cometd/cometd. Should this be appended to the
serverURL in dojox.cometd.init(serverURL) ? and how is the channel
related to the context? It seems that the handshake occurs as long as
the ip:port is correct.
thanks.
--Zaid
http://altmobile.com/Home.html
On Jan 21, 2008, at 9:55 AM, Jeanfrancois Arcand wrote:
> Hi,
>
> OK thanks. For sure we need to catch such exception, but not sure
> how come we get it :-) Which version of DOJO are you using?
>
> Thanks
>
> -- Jeanfrancois
>
> ALT Mobile DEV wrote:
>> Hi and thanks for the response. There is no manipulation on my part
>> as this is all handled by Grizzly.
>> In my last post I did a screen shot of our http monitor so perhaps
>> Safari or Dojo is not encoding correctly.
>> --Zaid
>> http://altmobile.com
>> On Jan 18, 2008, at 6:53 PM, Shing Wai Chan <Shing-
>> Wai.Chan_at_Sun.COM> wrote:
>>> ALT Mobile DEV wrote:
>>>>
>>>>>> I was running the chat sample from the GlassFish download to
>>>>>> ensure that my CometHandler was working but got this:
>>>>>> Jan 18, 2008 8:45:09 AM
>>>>>> com.sun.grizzly.standalone.StaticResourcesAdapter <init>
>>>>>> INFO: New Servicing page from: /Users/.../ALTMobile/objsvr
>>>>>> Bayeux Server startup in 153 ms
>>>>>> Jan 18, 2008 8:48:34 AM
>>>>>> com.sun.grizzly.http.DefaultProcessorTask invokeAdapter
>>>>>> SEVERE: processorTask.serviceError
>>>>>> java.lang.ClassCastException: java.lang.Double cannot be cast
>>>>>> to java.lang.String
>>>>>> at
>>>>>> com
>>>>>> .sun
>>>>>> .grizzly.cometd.bayeux.VerbUtils.newHandshake(VerbUtils.java:125)
>>>>>> at
>>>>>> com.sun.grizzly.cometd.bayeux.VerbUtils.parseMap(VerbUtils.java:
>>>>>> 97)
>>>>>> at
>>>>>> com.sun.grizzly.cometd.bayeux.VerbUtils.parse(VerbUtils.java:69)
>>>>>> at
>>>>>> com
>>>>>> .sun.grizzly.cometd.EventRouterImpl.route(EventRouterImpl.java:
>>>>>> 91)
>>>>>> at
>>>>>> com
>>>>>> .sun
>>>>>> .grizzly
>>>>>> .cometd.standalone.CometdAdapter.service(CometdAdapter.java:
>>>>>> 240) at
>>>>>> com
>>>>>> .sun
>>>>>> .grizzly
>>>>>> .http
>>>>>> .DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:
>>>>>> 599) at
>>>>>> com
>>>>>> .sun.grizzly.comet.CometEngine.executeServlet(CometEngine.java:
>>>>>> 547)
>>>>>> at com.sun.grizzly.comet.CometEngine.handle(CometEngine.java:
>>>>>> 299)
>>>>>> at
>>>>>> com
>>>>>> .sun
>>>>>> .grizzly.comet.CometAsyncFilter.doFilter(CometAsyncFilter.java:
>>>>>> 87)
>>>>>> at
>>>>>> com
>>>>>> .sun
>>>>>> .grizzly
>>>>>> .arp
>>>>>> .DefaultAsyncExecutor.invokeFilters(DefaultAsyncExecutor.java:
>>>>>> 162) at
>>>>>> com
>>>>>> .sun
>>>>>> .grizzly
>>>>>> .arp.DefaultAsyncExecutor.interrupt(DefaultAsyncExecutor.java:
>>>>>> 140) at
>>>>>> com
>>>>>> .sun
>>>>>> .grizzly.arp.AsyncProcessorTask.doTask(AsyncProcessorTask.java:
>>>>>> 79)
>>>>>> at com.sun.grizzly.http.TaskBase.call(TaskBase.java:346)
>>>>>> at
>>>>>> com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:
>>>>>> 179)
>>>>>> I haven't had the chance to study and modify the JavaScript but
>>>>>> I wanted you to see if I missed something fundamental.
>>>>>
>>>>> Hum...this is strange. Is this with the trunk? Which version of
>>>>> Grizzly? Can you post your Javascript?
>>> According to the above stack trace, the version number is passed
>>> as double in request.
>>> This is not correct according to Bayeux Protocol:
>>>
>>> version = integer *( "." version_element )
>>> version_element = alphanum *( alphanum | "-" | "_" )
>>>
>>> It should be a String. How is the request generated?
>>> Regards,
>>> Shing Wai Chan
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>