[Q] Grizzlets update clients connected to different servers

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[Q] Grizzlets update clients connected to different servers

ALT Mobile DEV
Hi,

I'm running multiple servers in the same JVM where each server is  
associated with a different instance of the same Grizllet class. Each  
server of course is bound to a different port.

Confusingly, the unique content from each Grizzlet is pushed to all  
clients irrespective of the server:port they are connected.

It seems that the AsyncConnection is shared across all Grizzlets and  
servers.

I was expecting that:

Grizzly server = unique port + unique Grizzlet instance + unique comet  
context.


thanks for any help.


--Zaid

http://altmobile.com





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Grizzlets update clients connected to different servers

Jeanfrancois Arcand-2
Hi,

ALT Mobile DEV wrote:
> Hi,
>
> I'm running multiple servers in the same JVM where each server is
> associated with a different instance of the same Grizllet class. Each
> server of course is bound to a different port.
>
> Confusingly, the unique content from each Grizzlet is pushed to all
> clients irrespective of the server:port they are connected.

Yes :-( I didn't expected that Grizzly will be used like you just
explained. Mainly, since Grizzly build on top of Grizzly Comet, the
CometHandler I did for Grizzly is registered as '/comet'. Since there is
only one CometEngine (this is a singleton), all Grizzlet will be invoked
when the Grizzly Comet do a push, as internally it will do:

cometContext.notify(...);

and the cometContext is bind to 'comet'.

>
> It seems that the AsyncConnection is shared across all Grizzlets and
> servers.
>
> I was expecting that:
>
> Grizzly server = unique port + unique Grizzlet instance + unique comet
> context.

OK I've just added a new API to let you customize the cometContextName.
When you initialize the GrizzlyAdapter, just pass the name of the
cometContext you want to use. In your case, it can be the just the port
like the following:

>     113         AsyncHandler asyncHandler = new DefaultAsyncHandler();
>     114         asyncHandler.addAsyncFilter(new CometAsyncFilter());
>     115         selectorThread.setAsyncHandler(asyncHandler);
>     116
>     117
>     118         GrizzletAdapter adapter = new GrizzletAdapter(String.valueOf(port));
>     119         selectorThread.setAdapter(adapter);
>     120         Grizzlet grizzlet = (Grizzlet)loadInstance(grizzletClassName);
>     121

Try it and let me know if that works :-) I've uploaded the new artifacts
to the m2 repository, or you can rebuild the comet module to get the
changes.

Thanks

-- Jeanfrancois



>
>
> thanks for any help.
>
>
> --Zaid
>
> http://altmobile.com
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Grizzlets update clients connected to different servers

Jeanfrancois Arcand-2


Jeanfrancois Arcand wrote:

> Hi,
>
> ALT Mobile DEV wrote:
>> Hi,
>>
>> I'm running multiple servers in the same JVM where each server is
>> associated with a different instance of the same Grizllet class. Each
>> server of course is bound to a different port.
>>
>> Confusingly, the unique content from each Grizzlet is pushed to all
>> clients irrespective of the server:port they are connected.
>
> Yes :-( I didn't expected that Grizzly will be used like you just
> explained. Mainly, since Grizzly build on top of Grizzly Comet, the
> CometHandler I did for Grizzly is registered as '/comet'. Since there is
> only one CometEngine (this is a singleton), all Grizzlet will be invoked
> when the Grizzly Comet do a push, as internally it will do:

Should have read:

 > Yes :-( I didn't expected that GrizzLET will be used like you just
 > explained. Mainly, since GrizzLET build on top of Grizzly Comet, the
 > CometHandler I did for GrizzLET is registered as '/comet'. Since
there is
 > only one CometEngine (this is a singleton), all Grizzlets will be
invoked
 > when the Grizzly Comet do a push, as internally it will do:

Its Grizzlet that build on top of Grizzly Comet, nor Grizzly :-)

A+

--jeanfrancois



>
> cometContext.notify(...);
>
> and the cometContext is bind to 'comet'.
>
>>
>> It seems that the AsyncConnection is shared across all Grizzlets and
>> servers.
>>
>> I was expecting that:
>>
>> Grizzly server = unique port + unique Grizzlet instance + unique comet
>> context.
>
> OK I've just added a new API to let you customize the cometContextName.
> When you initialize the GrizzlyAdapter, just pass the name of the
> cometContext you want to use. In your case, it can be the just the port
> like the following:
>
>>     113         AsyncHandler asyncHandler = new DefaultAsyncHandler();
>>     114         asyncHandler.addAsyncFilter(new CometAsyncFilter());
>>     115         selectorThread.setAsyncHandler(asyncHandler);
>>     116     117     118         GrizzletAdapter adapter = new
>> GrizzletAdapter(String.valueOf(port));
>>     119         selectorThread.setAdapter(adapter);
>>     120         Grizzlet grizzlet =
>> (Grizzlet)loadInstance(grizzletClassName);
>>     121
>
> Try it and let me know if that works :-) I've uploaded the new artifacts
> to the m2 repository, or you can rebuild the comet module to get the
> changes.
>
> Thanks
>
> -- Jeanfrancois
>
>
>
>>
>>
>> thanks for any help.
>>
>>
>> --Zaid
>>
>> http://altmobile.com
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Grizzlets update clients connected to different servers

ALT Mobile DEV
In reply to this post by Jeanfrancois Arcand-2
thanks for the quick responses.

Will this also support non-cometd Grizzlets where the client does  
_not_ specify a  comet path.

In our Dynamic Mashup Server, we want to allow the client to specify  
the behavior of the server through URL parameters.

So an AJAX client will use a URL such as <a href="http://altmobile.com:xxx">http://altmobile.com:xxx

and a long-polling Comet client will use a URL such as http://altmobile.com 
:xxx?use-comet&refresh-increment=5

and a Bayeux Comet client will use a predefined Comet context path  
such as the URL <a href="http://altmobile.com:xxx/comet?use-comet&refresh-">http://altmobile.com:xxx/comet?use-comet&refresh- 
increment=5


That's our plan for Grizzly. Do you think that this is doable with the  
Grizzlet architecture?

thanks.

--Zaid

http://altmobile.com



On Jan 15, 2008, at 10:11 PM, Jeanfrancois Arcand wrote:

> Hi,
>
> ALT Mobile DEV wrote:
>> Hi,
>> I'm running multiple servers in the same JVM where each server is  
>> associated with a different instance of the same Grizllet class.  
>> Each server of course is bound to a different port.
>> Confusingly, the unique content from each Grizzlet is pushed to all  
>> clients irrespective of the server:port they are connected.
>
> Yes :-( I didn't expected that Grizzly will be used like you just  
> explained. Mainly, since Grizzly build on top of Grizzly Comet, the  
> CometHandler I did for Grizzly is registered as '/comet'. Since  
> there is only one CometEngine (this is a singleton), all Grizzlet  
> will be invoked when the Grizzly Comet do a push, as internally it  
> will do:
>
> cometContext.notify(...);
>
> and the cometContext is bind to 'comet'.
>
>> It seems that the AsyncConnection is shared across all Grizzlets  
>> and servers.
>> I was expecting that:
>> Grizzly server = unique port + unique Grizzlet instance + unique  
>> comet context.
>
> OK I've just added a new API to let you customize the  
> cometContextName. When you initialize the GrizzlyAdapter, just pass  
> the name of the cometContext you want to use. In your case, it can  
> be the just the port like the following:
>
>>    113         AsyncHandler asyncHandler = new DefaultAsyncHandler();
>>    114         asyncHandler.addAsyncFilter(new CometAsyncFilter());
>>    115         selectorThread.setAsyncHandler(asyncHandler);
>>    116     117     118         GrizzletAdapter adapter = new  
>> GrizzletAdapter(String.valueOf(port));
>>    119         selectorThread.setAdapter(adapter);
>>    120         Grizzlet grizzlet =  
>> (Grizzlet)loadInstance(grizzletClassName);
>>    121
>
> Try it and let me know if that works :-) I've uploaded the new  
> artifacts to the m2 repository, or you can rebuild the comet module  
> to get the changes.
>
> Thanks
>
> -- Jeanfrancois
>
>
>
>> thanks for any help.
>> --Zaid
>> http://altmobile.com
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[Q] Bayeux Comet example with Grizzlets [was: Re: [Q] Grizzlets update clients connected to different servers]

ALT Mobile DEV
In reply to this post by Jeanfrancois Arcand-2
as expected... perfect :-)

Do you have a Bayeux Comet example with Grizzlets?


continued thanks.

--Zaid

http://altmobile.com


On Jan 15, 2008, at 10:16 PM, Jeanfrancois Arcand wrote:

>
>
> Jeanfrancois Arcand wrote:
>> Hi,
>> ALT Mobile DEV wrote:
>>> Hi,
>>>
>>> I'm running multiple servers in the same JVM where each server is  
>>> associated with a different instance of the same Grizllet class.  
>>> Each server of course is bound to a different port.
>>>
>>> Confusingly, the unique content from each Grizzlet is pushed to  
>>> all clients irrespective of the server:port they are connected.
>> Yes :-( I didn't expected that Grizzly will be used like you just  
>> explained. Mainly, since Grizzly build on top of Grizzly Comet, the  
>> CometHandler I did for Grizzly is registered as '/comet'. Since  
>> there is only one CometEngine (this is a singleton), all Grizzlet  
>> will be invoked when the Grizzly Comet do a push, as internally it  
>> will do:
>
> Should have read:
>
> > Yes :-( I didn't expected that GrizzLET will be used like you just
> > explained. Mainly, since GrizzLET build on top of Grizzly Comet, the
> > CometHandler I did for GrizzLET is registered as '/comet'. Since  
> there is
> > only one CometEngine (this is a singleton), all Grizzlets will be  
> invoked
> > when the Grizzly Comet do a push, as internally it will do:
>
> Its Grizzlet that build on top of Grizzly Comet, nor Grizzly :-)
>
> A+
>
> --jeanfrancois
>
>
>
>> cometContext.notify(...);
>> and the cometContext is bind to 'comet'.
>>>
>>> It seems that the AsyncConnection is shared across all Grizzlets  
>>> and servers.
>>>
>>> I was expecting that:
>>>
>>> Grizzly server = unique port + unique Grizzlet instance + unique  
>>> comet context.
>> OK I've just added a new API to let you customize the  
>> cometContextName. When you initialize the GrizzlyAdapter, just pass  
>> the name of the cometContext you want to use. In your case, it can  
>> be the just the port like the following:
>>>    113         AsyncHandler asyncHandler = new  
>>> DefaultAsyncHandler();
>>>    114         asyncHandler.addAsyncFilter(new CometAsyncFilter());
>>>    115         selectorThread.setAsyncHandler(asyncHandler);
>>>    116     117     118         GrizzletAdapter adapter = new  
>>> GrizzletAdapter(String.valueOf(port));
>>>    119         selectorThread.setAdapter(adapter);
>>>    120         Grizzlet grizzlet =  
>>> (Grizzlet)loadInstance(grizzletClassName);
>>>    121
>> Try it and let me know if that works :-) I've uploaded the new  
>> artifacts to the m2 repository, or you can rebuild the comet module  
>> to get the changes.
>> Thanks
>> -- Jeanfrancois
>>>
>>>
>>> thanks for any help.
>>>
>>>
>>> --Zaid
>>>
>>> http://altmobile.com
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Grizzlets update clients connected to different servers

Jeanfrancois Arcand-2
In reply to this post by ALT Mobile DEV
Salut,

ALT Mobile DEV wrote:
> thanks for the quick responses.
>
> Will this also support non-cometd Grizzlets where the client does _not_
> specify a  comet path.

Yes it will.

>
> In our Dynamic Mashup Server, we want to allow the client to specify the
> behavior of the server through URL parameters.
>
> So an AJAX client will use a URL such as <a href="http://altmobile.com:xxx">http://altmobile.com:xxx
>
> and a long-polling Comet client will use a URL such as
> <a href="http://altmobile.com:xxx?use-comet&refresh-increment=5">http://altmobile.com:xxx?use-comet&refresh-increment=5
>
> and a Bayeux Comet client will use a predefined Comet context path such
> as the URL <a href="http://altmobile.com:xxx/comet?use-comet&refresh-increment=5">http://altmobile.com:xxx/comet?use-comet&refresh-increment=5

OK let me ask a couple of questions. Here you seems to use two concepts:

(1) Comet: Some Ajax clients send http request and the body (the
message) is based on some custom protocol/messages.

(2) Cometd/Bayeux: Some Ajax clients send http message and the body (the
message) is written using Bayeux (JSON).

This is quite interesting If I understand properly :-)

>
>
> That's our plan for Grizzly. Do you think that this is doable with the
> Grizzlet architecture?

Yes it will, but you gonna need to bootstrap/embed the grizzly-cometd
module AND the Grizzlet (like you already did). Now when you listen to a
port (let say 3434), can that port receive both comet and cometd
requests? Currently a port support comet *or* cometd, but not both (this
is quite simple to implement btw).

Thanks

-- Jeanfrancois


>
> thanks.
>
> --Zaid
>
> http://altmobile.com
>
>
>
> On Jan 15, 2008, at 10:11 PM, Jeanfrancois Arcand wrote:
>
>> Hi,
>>
>> ALT Mobile DEV wrote:
>>> Hi,
>>> I'm running multiple servers in the same JVM where each server is
>>> associated with a different instance of the same Grizllet class. Each
>>> server of course is bound to a different port.
>>> Confusingly, the unique content from each Grizzlet is pushed to all
>>> clients irrespective of the server:port they are connected.
>>
>> Yes :-( I didn't expected that Grizzly will be used like you just
>> explained. Mainly, since Grizzly build on top of Grizzly Comet, the
>> CometHandler I did for Grizzly is registered as '/comet'. Since there
>> is only one CometEngine (this is a singleton), all Grizzlet will be
>> invoked when the Grizzly Comet do a push, as internally it will do:
>>
>> cometContext.notify(...);
>>
>> and the cometContext is bind to 'comet'.
>>
>>> It seems that the AsyncConnection is shared across all Grizzlets and
>>> servers.
>>> I was expecting that:
>>> Grizzly server = unique port + unique Grizzlet instance + unique
>>> comet context.
>>
>> OK I've just added a new API to let you customize the
>> cometContextName. When you initialize the GrizzlyAdapter, just pass
>> the name of the cometContext you want to use. In your case, it can be
>> the just the port like the following:
>>
>>>    113         AsyncHandler asyncHandler = new DefaultAsyncHandler();
>>>    114         asyncHandler.addAsyncFilter(new CometAsyncFilter());
>>>    115         selectorThread.setAsyncHandler(asyncHandler);
>>>    116     117     118         GrizzletAdapter adapter = new
>>> GrizzletAdapter(String.valueOf(port));
>>>    119         selectorThread.setAdapter(adapter);
>>>    120         Grizzlet grizzlet =
>>> (Grizzlet)loadInstance(grizzletClassName);
>>>    121
>>
>> Try it and let me know if that works :-) I've uploaded the new
>> artifacts to the m2 repository, or you can rebuild the comet module to
>> get the changes.
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>>
>>
>>> thanks for any help.
>>> --Zaid
>>> http://altmobile.com
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Bayeux Comet example with Grizzlets [was: Re: [Q] Grizzlets update clients connected to different servers]

Jeanfrancois Arcand-2
In reply to this post by ALT Mobile DEV


ALT Mobile DEV wrote:
> as expected... perfect :-)

Thanks

>
> Do you have a Bayeux Comet example with Grizzlets?

Since cometd is a client side technology, you don't need to write any
Grizzlet as by default, a cometd client will work with any web server
that support the bayeux protocol (JSON based). Take a look at the
following blog for a client examples

http://weblogs.java.net/blog/jfarcand/archive/2007/11/finally_grizzly.html

the way it works is the DOJO client is sending http request, and the
request body take the form of a JSON message. On the server side,
Grizzly Cometd implementation receive the request, decode the JSON
message and execute the proper operation. Like I've said, any web server
that understand bayeux will be able to decode the message.

Now you might want to have client that aren't supporting bayeux (they
*don't* encode the request body using JSON) to be able to interact with
the cometd 'channel' (be able to update bayeux clients). To do that, you
  can use Grizzly Comet or Grizzlet to get notification (or to push)
data to those client. Before I go into the details, are you planning to
use Comet *and* Cometd client (and do they have to interact each other
via Grizzy Comet or Cometd)?

If yes, get ready to get a long email explaining how to do it :-) :-)

A+

-- Jeanfrancois


>
>
> continued thanks.
>
> --Zaid
>
> http://altmobile.com
>
>
> On Jan 15, 2008, at 10:16 PM, Jeanfrancois Arcand wrote:
>
>>
>>
>> Jeanfrancois Arcand wrote:
>>> Hi,
>>> ALT Mobile DEV wrote:
>>>> Hi,
>>>>
>>>> I'm running multiple servers in the same JVM where each server is
>>>> associated with a different instance of the same Grizllet class.
>>>> Each server of course is bound to a different port.
>>>>
>>>> Confusingly, the unique content from each Grizzlet is pushed to all
>>>> clients irrespective of the server:port they are connected.
>>> Yes :-( I didn't expected that Grizzly will be used like you just
>>> explained. Mainly, since Grizzly build on top of Grizzly Comet, the
>>> CometHandler I did for Grizzly is registered as '/comet'. Since there
>>> is only one CometEngine (this is a singleton), all Grizzlet will be
>>> invoked when the Grizzly Comet do a push, as internally it will do:
>>
>> Should have read:
>>
>> > Yes :-( I didn't expected that GrizzLET will be used like you just
>> > explained. Mainly, since GrizzLET build on top of Grizzly Comet, the
>> > CometHandler I did for GrizzLET is registered as '/comet'. Since
>> there is
>> > only one CometEngine (this is a singleton), all Grizzlets will be
>> invoked
>> > when the Grizzly Comet do a push, as internally it will do:
>>
>> Its Grizzlet that build on top of Grizzly Comet, nor Grizzly :-)
>>
>> A+
>>
>> --jeanfrancois
>>
>>
>>
>>> cometContext.notify(...);
>>> and the cometContext is bind to 'comet'.
>>>>
>>>> It seems that the AsyncConnection is shared across all Grizzlets and
>>>> servers.
>>>>
>>>> I was expecting that:
>>>>
>>>> Grizzly server = unique port + unique Grizzlet instance + unique
>>>> comet context.
>>> OK I've just added a new API to let you customize the
>>> cometContextName. When you initialize the GrizzlyAdapter, just pass
>>> the name of the cometContext you want to use. In your case, it can be
>>> the just the port like the following:
>>>>    113         AsyncHandler asyncHandler = new DefaultAsyncHandler();
>>>>    114         asyncHandler.addAsyncFilter(new CometAsyncFilter());
>>>>    115         selectorThread.setAsyncHandler(asyncHandler);
>>>>    116     117     118         GrizzletAdapter adapter = new
>>>> GrizzletAdapter(String.valueOf(port));
>>>>    119         selectorThread.setAdapter(adapter);
>>>>    120         Grizzlet grizzlet =
>>>> (Grizzlet)loadInstance(grizzletClassName);
>>>>    121
>>> Try it and let me know if that works :-) I've uploaded the new
>>> artifacts to the m2 repository, or you can rebuild the comet module
>>> to get the changes.
>>> Thanks
>>> -- Jeanfrancois
>>>>
>>>>
>>>> thanks for any help.
>>>>
>>>>
>>>> --Zaid
>>>>
>>>> http://altmobile.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Grizzlets update clients connected to different servers

ALT Mobile DEV
In reply to this post by Jeanfrancois Arcand-2
Hi,

my response is embedded... thanks again


--Zaid

altmobile.com

On Jan 16, 2008, at 11:38 AM, Jeanfrancois Arcand wrote:

> Salut,
>
> ALT Mobile DEV wrote:
>> thanks for the quick responses.
>> Will this also support non-cometd Grizzlets where the client does  
>> _not_ specify a  comet path.
>
> Yes it will.
>
>> In our Dynamic Mashup Server, we want to allow the client to  
>> specify the behavior of the server through URL parameters.
>> So an AJAX client will use a URL such as <a href="http://altmobile.com:xxx">http://altmobile.com:xxx
>> and a long-polling Comet client will use a URL such as http://altmobile.com 
>> :xxx?use-comet&refresh-increment=5
>> and a Bayeux Comet client will use a predefined Comet context path  
>> such as the URL <a href="http://altmobile.com:xxx/comet?use-comet&refresh-">http://altmobile.com:xxx/comet?use-comet&refresh- 
>> increment=5
>
> OK let me ask a couple of questions. Here you seems to use two  
> concepts:
>
> (1) Comet: Some Ajax clients send http request and the body (the  
> message) is based on some custom protocol/messages.
>
> (2) Cometd/Bayeux: Some Ajax clients send http message and the body  
> (the message) is written using Bayeux (JSON).
>
> This is quite interesting If I understand properly :-)

[ZAID] yes, that is correct. Much like you created Grizzlets to  
simplify Comet and Servlet programming and deployment and etc. we have  
also simplified mash-up programming, testing, and deployment.  
Conceptually, a mash-up aggregates parts of 1 or more remote web sites  
with some local content. Perhaps a mash-up would be a few paragraphs  
from Wikipedia on Comet, the titles of your blogs on Comet excluding  
JRuby and GlassFish, a few pictures and bios of the Grizzy team, and a  
table of the JAR files for the various Grizzly bundles. That's about  
10 http requests to create this virtual tutorial web site on Grizzly.

Our Dynamic Mashup Server provides virtualized Web 2.0 containers  
which isolate each mash-up. The user can consume the mash-up as a  
JavaFX client, iPhone client, Apple Dashboard widget, MS Vista Gadget,  
RSS feed, text-to-speech audio, etc, etc. The Dynamic Mashup Server  
uses code generation to output the appropriate type based on the  
client request and client capabilities.

The glue between our Web 2.0 containers and the clients is of course  
Grizzly but the end user's mental model is about the XSL that creates  
their mash-up page and the URL parameters which control the Dynamic  
Mashup Server's output.

So we want the end user to be able to consume their mash-up with a  
long-polling Comet client by using the URL parameter "use-comet" just  
like if the user was visually impaired she could use the parameter  
"use-TTS" to get a text-to-speech audio of the mash-up results.  It's  
not very RESTful, but it's the best approach for mash-up programming  
or else you would have 15+ unique URLs from each mash-up which is not  
a manageable solution for the end user.

So, yes we hope to run both Comet and Cometd on the same port  
hopefully using the nice Web 2.0 container friendly POJO model that  
Grizzlets provide.



>
>
>> That's our plan for Grizzly. Do you think that this is doable with  
>> the Grizzlet architecture?
>
> Yes it will, but you gonna need to bootstrap/embed the grizzly-
> cometd module AND the Grizzlet (like you already did). Now when you  
> listen to a port (let say 3434), can that port receive both comet  
> and cometd requests? Currently a port support comet *or* cometd, but  
> not both (this is quite simple to implement btw).
>
> Thanks
>
> -- Jeanfrancois
>
>
>> thanks.
>> --Zaid
>> http://altmobile.com
>> On Jan 15, 2008, at 10:11 PM, Jeanfrancois Arcand wrote:
>>> Hi,
>>>
>>> ALT Mobile DEV wrote:
>>>> Hi,
>>>> I'm running multiple servers in the same JVM where each server is  
>>>> associated with a different instance of the same Grizllet class.  
>>>> Each server of course is bound to a different port.
>>>> Confusingly, the unique content from each Grizzlet is pushed to  
>>>> all clients irrespective of the server:port they are connected.
>>>
>>> Yes :-( I didn't expected that Grizzly will be used like you just  
>>> explained. Mainly, since Grizzly build on top of Grizzly Comet,  
>>> the CometHandler I did for Grizzly is registered as '/comet'.  
>>> Since there is only one CometEngine (this is a singleton), all  
>>> Grizzlet will be invoked when the Grizzly Comet do a push, as  
>>> internally it will do:
>>>
>>> cometContext.notify(...);
>>>
>>> and the cometContext is bind to 'comet'.
>>>
>>>> It seems that the AsyncConnection is shared across all Grizzlets  
>>>> and servers.
>>>> I was expecting that:
>>>> Grizzly server = unique port + unique Grizzlet instance + unique  
>>>> comet context.
>>>
>>> OK I've just added a new API to let you customize the  
>>> cometContextName. When you initialize the GrizzlyAdapter, just  
>>> pass the name of the cometContext you want to use. In your case,  
>>> it can be the just the port like the following:
>>>
>>>>   113         AsyncHandler asyncHandler = new  
>>>> DefaultAsyncHandler();
>>>>   114         asyncHandler.addAsyncFilter(new CometAsyncFilter());
>>>>   115         selectorThread.setAsyncHandler(asyncHandler);
>>>>   116     117     118         GrizzletAdapter adapter = new  
>>>> GrizzletAdapter(String.valueOf(port));
>>>>   119         selectorThread.setAdapter(adapter);
>>>>   120         Grizzlet grizzlet =  
>>>> (Grizzlet)loadInstance(grizzletClassName);
>>>>   121
>>>
>>> Try it and let me know if that works :-) I've uploaded the new  
>>> artifacts to the m2 repository, or you can rebuild the comet  
>>> module to get the changes.
>>>
>>> Thanks
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>
>>>> thanks for any help.
>>>> --Zaid
>>>> http://altmobile.com
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Bayeux Comet example with Grizzlets [was: Re: [Q] Grizzlets update clients connected to different servers]

ALT Mobile DEV
In reply to this post by Jeanfrancois Arcand-2
Hi and thank you for all the help.

My response is embedded below.

--Zaid

http://altmobile.com


On Jan 16, 2008, at 11:46 AM, Jeanfrancois Arcand wrote:

>
>
> ALT Mobile DEV wrote:
>> as expected... perfect :-)
>
> Thanks
>
>> Do you have a Bayeux Comet example with Grizzlets?
>
> Since cometd is a client side technology, you don't need to write  
> any Grizzlet as by default, a cometd client will work with any web  
> server that support the bayeux protocol (JSON based). Take a look at  
> the following blog for a client examples
>
> http://weblogs.java.net/blog/jfarcand/archive/2007/11/finally_grizzly.html
>
> the way it works is the DOJO client is sending http request, and the  
> request body take the form of a JSON message. On the server side,  
> Grizzly Cometd implementation receive the request, decode the JSON  
> message and execute the proper operation. Like I've said, any web  
> server that understand bayeux will be able to decode the message.

[ZAID] yes, I used the blog as a reference for our current Grizzlet  
implementation but it was not obvious to me how is the channel/
operation exposed to the Grizzlet:

[72] String action = req.getParameterValues("action")[0];
[73] String name = req.getParameterValues("name")[0];


Our current implementation of the Dynamic Mashup Server runs 1 mash-up  
on each Grizzly server which is connected to the Web 2.0 containers.  
That architecture works well for consumer mash-ups. An alternative use  
case is found in enterprise dashboard-style mash-ups where the AJAX  
browser client wants to display multiple mash-ups on the same page.  
For example, a GlassFish dashboard could display the compilation  
status/bug list of each GlassFish component. So that's 10+ mash-ups  
where each mash-up aggregates 2 remote HTTP calls: 1 for the bug list  
and another for the continues integration stuff.

If a Cometd/Bayeux client can request multiple channels/operations to  
the server (port, Grizzly server, Grizzlet, Web 2.0 container) then  
that's the bees knees since we can selectively update specific aspects  
of this meta mash-up client.


>
>
> Now you might want to have client that aren't supporting bayeux  
> (they *don't* encode the request body using JSON) to be able to  
> interact with the cometd 'channel' (be able to update bayeux  
> clients). To do that, you  can use Grizzly Comet or Grizzlet to get  
> notification (or to push) data to those client. Before I go into the  
> details, are you planning to use Comet *and* Cometd client (and do  
> they have to interact each other via Grizzy Comet or Cometd)?
>

[ZAID] yes, with your help :-)


> If yes, get ready to get a long email explaining how to do it :-) :-)
>
> A+
>
> -- Jeanfrancois
>
>
>> continued thanks.
>> --Zaid
>> http://altmobile.com
>> On Jan 15, 2008, at 10:16 PM, Jeanfrancois Arcand wrote:
>>>
>>>
>>> Jeanfrancois Arcand wrote:
>>>> Hi,
>>>> ALT Mobile DEV wrote:
>>>>> Hi,
>>>>>
>>>>> I'm running multiple servers in the same JVM where each server  
>>>>> is associated with a different instance of the same Grizllet  
>>>>> class. Each server of course is bound to a different port.
>>>>>
>>>>> Confusingly, the unique content from each Grizzlet is pushed to  
>>>>> all clients irrespective of the server:port they are connected.
>>>> Yes :-( I didn't expected that Grizzly will be used like you just  
>>>> explained. Mainly, since Grizzly build on top of Grizzly Comet,  
>>>> the CometHandler I did for Grizzly is registered as '/comet'.  
>>>> Since there is only one CometEngine (this is a singleton), all  
>>>> Grizzlet will be invoked when the Grizzly Comet do a push, as  
>>>> internally it will do:
>>>
>>> Should have read:
>>>
>>> > Yes :-( I didn't expected that GrizzLET will be used like you just
>>> > explained. Mainly, since GrizzLET build on top of Grizzly Comet,  
>>> the
>>> > CometHandler I did for GrizzLET is registered as '/comet'. Since  
>>> there is
>>> > only one CometEngine (this is a singleton), all Grizzlets will  
>>> be invoked
>>> > when the Grizzly Comet do a push, as internally it will do:
>>>
>>> Its Grizzlet that build on top of Grizzly Comet, nor Grizzly :-)
>>>
>>> A+
>>>
>>> --jeanfrancois
>>>
>>>
>>>
>>>> cometContext.notify(...);
>>>> and the cometContext is bind to 'comet'.
>>>>>
>>>>> It seems that the AsyncConnection is shared across all Grizzlets  
>>>>> and servers.
>>>>>
>>>>> I was expecting that:
>>>>>
>>>>> Grizzly server = unique port + unique Grizzlet instance + unique  
>>>>> comet context.
>>>> OK I've just added a new API to let you customize the  
>>>> cometContextName. When you initialize the GrizzlyAdapter, just  
>>>> pass the name of the cometContext you want to use. In your case,  
>>>> it can be the just the port like the following:
>>>>>   113         AsyncHandler asyncHandler = new  
>>>>> DefaultAsyncHandler();
>>>>>   114         asyncHandler.addAsyncFilter(new CometAsyncFilter());
>>>>>   115         selectorThread.setAsyncHandler(asyncHandler);
>>>>>   116     117     118         GrizzletAdapter adapter = new  
>>>>> GrizzletAdapter(String.valueOf(port));
>>>>>   119         selectorThread.setAdapter(adapter);
>>>>>   120         Grizzlet grizzlet =  
>>>>> (Grizzlet)loadInstance(grizzletClassName);
>>>>>   121
>>>> Try it and let me know if that works :-) I've uploaded the new  
>>>> artifacts to the m2 repository, or you can rebuild the comet  
>>>> module to get the changes.
>>>> Thanks
>>>> -- Jeanfrancois
>>>>>
>>>>>
>>>>> thanks for any help.
>>>>>
>>>>>
>>>>> --Zaid
>>>>>
>>>>> http://altmobile.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Bayeux Comet example with Grizzlets [was: Re: [Q] Grizzlets update clients connected to different servers]

Jeanfrancois Arcand-2


ALT Mobile DEV wrote:

> Hi and thank you for all the help.
>
> My response is embedded below.
>
> --Zaid
>
> http://altmobile.com
>
>
> On Jan 16, 2008, at 11:46 AM, Jeanfrancois Arcand wrote:
>
>>
>>
>> ALT Mobile DEV wrote:
>>> as expected... perfect :-)
>>
>> Thanks
>>
>>> Do you have a Bayeux Comet example with Grizzlets?
>>
>> Since cometd is a client side technology, you don't need to write any
>> Grizzlet as by default, a cometd client will work with any web server
>> that support the bayeux protocol (JSON based). Take a look at the
>> following blog for a client examples
>>
>> http://weblogs.java.net/blog/jfarcand/archive/2007/11/finally_grizzly.html 
>>
>>
>> the way it works is the DOJO client is sending http request, and the
>> request body take the form of a JSON message. On the server side,
>> Grizzly Cometd implementation receive the request, decode the JSON
>> message and execute the proper operation. Like I've said, any web
>> server that understand bayeux will be able to decode the message.
>
> [ZAID] yes, I used the blog as a reference for our current Grizzlet
> implementation but it was not obvious to me how is the channel/operation
> exposed to the Grizzlet:
>
> [72] String action = req.getParameterValues("action")[0];
> [73] String name = req.getParameterValues("name")[0];
>
>
> Our current implementation of the Dynamic Mashup Server runs 1 mash-up
> on each Grizzly server which is connected to the Web 2.0 containers.
> That architecture works well for consumer mash-ups. An alternative use
> case is found in enterprise dashboard-style mash-ups where the AJAX
> browser client wants to display multiple mash-ups on the same page.  For
> example, a GlassFish dashboard could display the compilation status/bug
> list of each GlassFish component. So that's 10+ mash-ups where each
> mash-up aggregates 2 remote HTTP calls: 1 for the bug list and another
> for the continues integration stuff.
>
> If a Cometd/Bayeux client can request multiple channels/operations to
> the server (port, Grizzly server, Grizzlet, Web 2.0 container) then
> that's the bees knees since we can selectively update specific aspects
> of this meta mash-up client.
>
>
>>
>>
>> Now you might want to have client that aren't supporting bayeux (they
>> *don't* encode the request body using JSON) to be able to interact
>> with the cometd 'channel' (be able to update bayeux clients). To do
>> that, you  can use Grizzly Comet or Grizzlet to get notification (or
>> to push) data to those client. Before I go into the details, are you
>> planning to use Comet *and* Cometd client (and do they have to
>> interact each other via Grizzy Comet or Cometd)?
>>
>
> [ZAID] yes, with your help :-)
>
>
>> If yes, get ready to get a long email explaining how to do it :-) :-)

OK thank for the explanation. So what you need to do is to share
information between CometContext(s). One of your CometContext will be
the one registered with '/cometd', which is the one that support the
bayeux protocol. The first steps for you will consist of bootstrapping
the cometd implementation inside your Java startup classes

>     109         selectorThread.setWebAppRootPath(folder);
>     110
>     111         String adapterClass =  System.getProperty(ADAPTER);
>     112         Adapter adapter;
>     113         if (adapterClass == null){
>     114             adapter = new CometdAdapter();
>     115         } else {
>     116             adapter = (Adapter)loadInstance(adapterClass);
>     117         }

Next is to create a CometHandler who can be invoked everytime the cometd
CometContext is updated:

>
> CometHandler cometdListenerHandler = new CometHandler(){
>
> ....
>
>
> }
>
> CometEngine.getEngine().getCometContext("/cometd").addCometHandler(cometdListenerHandler);

So on every bayeux requests, the cometdListenerHandlsr.onEvent() will be
invoked, containing the JSON message. You can parse the message and do
something with it, like notifying other CometContext (ex: /comet_80) by
invoking:

> CometEngine.getEngine().getCometContext("/comet_80").notify(JSON_parsed_message);

By doing that, your Comet clients will be able to notified by Cometd
clients.

Does it make sense?

Thanks!

-- Jeanfrancois






>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>> continued thanks.
>>> --Zaid
>>> http://altmobile.com
>>> On Jan 15, 2008, at 10:16 PM, Jeanfrancois Arcand wrote:
>>>>
>>>>
>>>> Jeanfrancois Arcand wrote:
>>>>> Hi,
>>>>> ALT Mobile DEV wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm running multiple servers in the same JVM where each server is
>>>>>> associated with a different instance of the same Grizllet class.
>>>>>> Each server of course is bound to a different port.
>>>>>>
>>>>>> Confusingly, the unique content from each Grizzlet is pushed to
>>>>>> all clients irrespective of the server:port they are connected.
>>>>> Yes :-( I didn't expected that Grizzly will be used like you just
>>>>> explained. Mainly, since Grizzly build on top of Grizzly Comet, the
>>>>> CometHandler I did for Grizzly is registered as '/comet'. Since
>>>>> there is only one CometEngine (this is a singleton), all Grizzlet
>>>>> will be invoked when the Grizzly Comet do a push, as internally it
>>>>> will do:
>>>>
>>>> Should have read:
>>>>
>>>> > Yes :-( I didn't expected that GrizzLET will be used like you just
>>>> > explained. Mainly, since GrizzLET build on top of Grizzly Comet, the
>>>> > CometHandler I did for GrizzLET is registered as '/comet'. Since
>>>> there is
>>>> > only one CometEngine (this is a singleton), all Grizzlets will be
>>>> invoked
>>>> > when the Grizzly Comet do a push, as internally it will do:
>>>>
>>>> Its Grizzlet that build on top of Grizzly Comet, nor Grizzly :-)
>>>>
>>>> A+
>>>>
>>>> --jeanfrancois
>>>>
>>>>
>>>>
>>>>> cometContext.notify(...);
>>>>> and the cometContext is bind to 'comet'.
>>>>>>
>>>>>> It seems that the AsyncConnection is shared across all Grizzlets
>>>>>> and servers.
>>>>>>
>>>>>> I was expecting that:
>>>>>>
>>>>>> Grizzly server = unique port + unique Grizzlet instance + unique
>>>>>> comet context.
>>>>> OK I've just added a new API to let you customize the
>>>>> cometContextName. When you initialize the GrizzlyAdapter, just pass
>>>>> the name of the cometContext you want to use. In your case, it can
>>>>> be the just the port like the following:
>>>>>>   113         AsyncHandler asyncHandler = new DefaultAsyncHandler();
>>>>>>   114         asyncHandler.addAsyncFilter(new CometAsyncFilter());
>>>>>>   115         selectorThread.setAsyncHandler(asyncHandler);
>>>>>>   116     117     118         GrizzletAdapter adapter = new
>>>>>> GrizzletAdapter(String.valueOf(port));
>>>>>>   119         selectorThread.setAdapter(adapter);
>>>>>>   120         Grizzlet grizzlet =
>>>>>> (Grizzlet)loadInstance(grizzletClassName);
>>>>>>   121
>>>>> Try it and let me know if that works :-) I've uploaded the new
>>>>> artifacts to the m2 repository, or you can rebuild the comet module
>>>>> to get the changes.
>>>>> Thanks
>>>>> -- Jeanfrancois
>>>>>>
>>>>>>
>>>>>> thanks for any help.
>>>>>>
>>>>>>
>>>>>> --Zaid
>>>>>>
>>>>>> http://altmobile.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Bayeux Comet example with Grizzlets [was: Re: [Q] Grizzlets update clients connected to different servers]

ALT Mobile DEV
Hi, I've embedded a few more questions... thanks for your continued  
help.

--Zaid

http://altmobile.com



On Jan 17, 2008, at 11:28 AM, Jeanfrancois Arcand wrote:

>
>
> ALT Mobile DEV wrote:
>> Hi and thank you for all the help.
>> My response is embedded below.
>> --Zaid
>> http://altmobile.com
>> On Jan 16, 2008, at 11:46 AM, Jeanfrancois Arcand wrote:
>>>
>>>
>>> ALT Mobile DEV wrote:
>>>> as expected... perfect :-)
>>>
>>> Thanks
>>>
>>>> Do you have a Bayeux Comet example with Grizzlets?
>>>
>>> Since cometd is a client side technology, you don't need to write  
>>> any Grizzlet as by default, a cometd client will work with any web  
>>> server that support the bayeux protocol (JSON based). Take a look  
>>> at the following blog for a client examples
>>>
>>> http://weblogs.java.net/blog/jfarcand/archive/2007/11/finally_grizzly.html
>>>
>>> the way it works is the DOJO client is sending http request, and  
>>> the request body take the form of a JSON message. On the server  
>>> side, Grizzly Cometd implementation receive the request, decode  
>>> the JSON message and execute the proper operation. Like I've said,  
>>> any web server that understand bayeux will be able to decode the  
>>> message.
>> [ZAID] yes, I used the blog as a reference for our current Grizzlet  
>> implementation but it was not obvious to me how is the channel/
>> operation exposed to the Grizzlet:
>> [72] String action = req.getParameterValues("action")[0];
>> [73] String name = req.getParameterValues("name")[0];
>> Our current implementation of the Dynamic Mashup Server runs 1 mash-
>> up on each Grizzly server which is connected to the Web 2.0  
>> containers. That architecture works well for consumer mash-ups. An  
>> alternative use case is found in enterprise dashboard-style mash-
>> ups where the AJAX browser client wants to display multiple mash-
>> ups on the same page.  For example, a GlassFish dashboard could  
>> display the compilation status/bug list of each GlassFish  
>> component. So that's 10+ mash-ups where each mash-up aggregates 2  
>> remote HTTP calls: 1 for the bug list and another for the continues  
>> integration stuff.
>> If a Cometd/Bayeux client can request multiple channels/operations  
>> to the server (port, Grizzly server, Grizzlet, Web 2.0 container)  
>> then that's the bees knees since we can selectively update specific  
>> aspects of this meta mash-up client.
>>>
>>>
>>> Now you might want to have client that aren't supporting bayeux  
>>> (they *don't* encode the request body using JSON) to be able to  
>>> interact with the cometd 'channel' (be able to update bayeux  
>>> clients). To do that, you  can use Grizzly Comet or Grizzlet to  
>>> get notification (or to push) data to those client. Before I go  
>>> into the details, are you planning to use Comet *and* Cometd  
>>> client (and do they have to interact each other via Grizzy Comet  
>>> or Cometd)?
>>>
>> [ZAID] yes, with your help :-)
>>> If yes, get ready to get a long email explaining how to do  
>>> it :-) :-)
>
> OK thank for the explanation. So what you need to do is to share  
> information between CometContext(s). One of your CometContext will  
> be the one registered with '/cometd', which is the one that support  
> the bayeux protocol. The first steps for you will consist of  
> bootstrapping the cometd implementation inside your Java startup  
> classes
>
>>    109         selectorThread.setWebAppRootPath(folder);
>>    110     111         String adapterClass =  
>> System.getProperty(ADAPTER);
>>    112         Adapter adapter;
>>    113         if (adapterClass == null){
>>    114             adapter = new CometdAdapter();
>>    115         } else {
>>    116             adapter = (Adapter)loadInstance(adapterClass);
>>    117         }
>

[ZAID] I assume that I do _not_ need to  create a new subclass of  
StaticResourcesAdapter since CometdAdapter registers the CometContext  
correctly. But, I must create a separate SelectorThread for the Bayeux  
clients and therefore open another port , since there is a 1:1  
relationship in Grizzly 1.7 between SelectorThread and Adapter.  Also,  
there does not seem a way for the Grizzlet to be invoked as with the  
standard GrizzletAdapter.


> Next is to create a CometHandler who can be invoked everytime the  
> cometd CometContext is updated:
>
>> CometHandler cometdListenerHandler = new CometHandler(){
>> ....
>> }
>> CometEngine.getEngine().getCometContext("/
>> cometd").addCometHandler(cometdListenerHandler);
>

[ZAID] If I understand correctly, this new CometHandler is simply for  
my app to process the JSON messages since the BayeuxCometHandler is  
doing the protocol work. The CometHandler takes the place of Grizzlets  
in non-Cometd code. Is this correct?


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.


> So on every bayeux requests, the cometdListenerHandlsr.onEvent()  
> will be invoked, containing the JSON message. You can parse the  
> message and do something with it, like notifying other CometContext  
> (ex: /comet_80) by invoking:
>
>> CometEngine.getEngine().getCometContext("/
>> comet_80").notify(JSON_parsed_message);

[ZAID] I haven't gotten this far but I'm hopeful :-)


>>
>
> By doing that, your Comet clients will be able to notified by Cometd  
> clients.
>
> Does it make sense?
>
> Thanks!
>
> -- Jeanfrancois
>
>
>
>
>
>
>>>
>>> A+
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>> continued thanks.
>>>> --Zaid
>>>> http://altmobile.com
>>>> On Jan 15, 2008, at 10:16 PM, Jeanfrancois Arcand wrote:
>>>>>
>>>>>
>>>>> Jeanfrancois Arcand wrote:
>>>>>> Hi,
>>>>>> ALT Mobile DEV wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm running multiple servers in the same JVM where each server  
>>>>>>> is associated with a different instance of the same Grizllet  
>>>>>>> class. Each server of course is bound to a different port.
>>>>>>>
>>>>>>> Confusingly, the unique content from each Grizzlet is pushed  
>>>>>>> to all clients irrespective of the server:port they are  
>>>>>>> connected.
>>>>>> Yes :-( I didn't expected that Grizzly will be used like you  
>>>>>> just explained. Mainly, since Grizzly build on top of Grizzly  
>>>>>> Comet, the CometHandler I did for Grizzly is registered as '/
>>>>>> comet'. Since there is only one CometEngine (this is a  
>>>>>> singleton), all Grizzlet will be invoked when the Grizzly Comet  
>>>>>> do a push, as internally it will do:
>>>>>
>>>>> Should have read:
>>>>>
>>>>> > Yes :-( I didn't expected that GrizzLET will be used like you  
>>>>> just
>>>>> > explained. Mainly, since GrizzLET build on top of Grizzly  
>>>>> Comet, the
>>>>> > CometHandler I did for GrizzLET is registered as '/comet'.  
>>>>> Since there is
>>>>> > only one CometEngine (this is a singleton), all Grizzlets will  
>>>>> be invoked
>>>>> > when the Grizzly Comet do a push, as internally it will do:
>>>>>
>>>>> Its Grizzlet that build on top of Grizzly Comet, nor Grizzly :-)
>>>>>
>>>>> A+
>>>>>
>>>>> --jeanfrancois
>>>>>
>>>>>
>>>>>
>>>>>> cometContext.notify(...);
>>>>>> and the cometContext is bind to 'comet'.
>>>>>>>
>>>>>>> It seems that the AsyncConnection is shared across all  
>>>>>>> Grizzlets and servers.
>>>>>>>
>>>>>>> I was expecting that:
>>>>>>>
>>>>>>> Grizzly server = unique port + unique Grizzlet instance +  
>>>>>>> unique comet context.
>>>>>> OK I've just added a new API to let you customize the  
>>>>>> cometContextName. When you initialize the GrizzlyAdapter, just  
>>>>>> pass the name of the cometContext you want to use. In your  
>>>>>> case, it can be the just the port like the following:
>>>>>>>  113         AsyncHandler asyncHandler = new  
>>>>>>> DefaultAsyncHandler();
>>>>>>>  114         asyncHandler.addAsyncFilter(new  
>>>>>>> CometAsyncFilter());
>>>>>>>  115         selectorThread.setAsyncHandler(asyncHandler);
>>>>>>>  116     117     118         GrizzletAdapter adapter = new  
>>>>>>> GrizzletAdapter(String.valueOf(port));
>>>>>>>  119         selectorThread.setAdapter(adapter);
>>>>>>>  120         Grizzlet grizzlet =  
>>>>>>> (Grizzlet)loadInstance(grizzletClassName);
>>>>>>>  121
>>>>>> Try it and let me know if that works :-) I've uploaded the new  
>>>>>> artifacts to the m2 repository, or you can rebuild the comet  
>>>>>> module to get the changes.
>>>>>> Thanks
>>>>>> -- Jeanfrancois
>>>>>>>
>>>>>>>
>>>>>>> thanks for any help.
>>>>>>>
>>>>>>>
>>>>>>> --Zaid
>>>>>>>
>>>>>>> http://altmobile.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Bayeux Comet example with Grizzlets [was: Re: [Q] Grizzlets update clients connected to different servers]

Jeanfrancois Arcand-2


ALT Mobile DEV wrote:

> Hi, I've embedded a few more questions... thanks for your continued help.
>
> --Zaid
>
> http://altmobile.com
>
>
>
> On Jan 17, 2008, at 11:28 AM, Jeanfrancois Arcand wrote:
>
>>
>>
>> ALT Mobile DEV wrote:
>>> Hi and thank you for all the help.
>>> My response is embedded below.
>>> --Zaid
>>> http://altmobile.com
>>> On Jan 16, 2008, at 11:46 AM, Jeanfrancois Arcand wrote:
>>>>
>>>>
>>>> ALT Mobile DEV wrote:
>>>>> as expected... perfect :-)
>>>>
>>>> Thanks
>>>>
>>>>> Do you have a Bayeux Comet example with Grizzlets?
>>>>
>>>> Since cometd is a client side technology, you don't need to write
>>>> any Grizzlet as by default, a cometd client will work with any web
>>>> server that support the bayeux protocol (JSON based). Take a look at
>>>> the following blog for a client examples
>>>>
>>>> http://weblogs.java.net/blog/jfarcand/archive/2007/11/finally_grizzly.html 
>>>>
>>>>
>>>> the way it works is the DOJO client is sending http request, and the
>>>> request body take the form of a JSON message. On the server side,
>>>> Grizzly Cometd implementation receive the request, decode the JSON
>>>> message and execute the proper operation. Like I've said, any web
>>>> server that understand bayeux will be able to decode the message.
>>> [ZAID] yes, I used the blog as a reference for our current Grizzlet
>>> implementation but it was not obvious to me how is the
>>> channel/operation exposed to the Grizzlet:
>>> [72] String action = req.getParameterValues("action")[0];
>>> [73] String name = req.getParameterValues("name")[0];
>>> Our current implementation of the Dynamic Mashup Server runs 1
>>> mash-up on each Grizzly server which is connected to the Web 2.0
>>> containers. That architecture works well for consumer mash-ups. An
>>> alternative use case is found in enterprise dashboard-style mash-ups
>>> where the AJAX browser client wants to display multiple mash-ups on
>>> the same page.  For example, a GlassFish dashboard could display the
>>> compilation status/bug list of each GlassFish component. So that's
>>> 10+ mash-ups where each mash-up aggregates 2 remote HTTP calls: 1 for
>>> the bug list and another for the continues integration stuff.
>>> If a Cometd/Bayeux client can request multiple channels/operations to
>>> the server (port, Grizzly server, Grizzlet, Web 2.0 container) then
>>> that's the bees knees since we can selectively update specific
>>> aspects of this meta mash-up client.
>>>>
>>>>
>>>> Now you might want to have client that aren't supporting bayeux
>>>> (they *don't* encode the request body using JSON) to be able to
>>>> interact with the cometd 'channel' (be able to update bayeux
>>>> clients). To do that, you  can use Grizzly Comet or Grizzlet to get
>>>> notification (or to push) data to those client. Before I go into the
>>>> details, are you planning to use Comet *and* Cometd client (and do
>>>> they have to interact each other via Grizzy Comet or Cometd)?
>>>>
>>> [ZAID] yes, with your help :-)
>>>> If yes, get ready to get a long email explaining how to do it :-) :-)
>>
>> OK thank for the explanation. So what you need to do is to share
>> information between CometContext(s). One of your CometContext will be
>> the one registered with '/cometd', which is the one that support the
>> bayeux protocol. The first steps for you will consist of bootstrapping
>> the cometd implementation inside your Java startup classes
>>
>>>    109         selectorThread.setWebAppRootPath(folder);
>>>    110     111         String adapterClass =  
>>> System.getProperty(ADAPTER);
>>>    112         Adapter adapter;
>>>    113         if (adapterClass == null){
>>>    114             adapter = new CometdAdapter();
>>>    115         } else {
>>>    116             adapter = (Adapter)loadInstance(adapterClass);
>>>    117         }
>>
>
> [ZAID] I assume that I do _not_ need to  create a new subclass of
> StaticResourcesAdapter since CometdAdapter registers the CometContext
> correctly. But, I must create a separate SelectorThread for the Bayeux
> clients and therefore open another port , since there is a 1:1
> relationship in Grizzly 1.7 between SelectorThread and Adapter.  

Exact. Multi-Adapter support is right now supported in GlassFish v3.
Having our own in Grizzly can be a good idea as well, but require more
work as you need to map the request with the proper adapter. I can take
a look if you need it and help testing :-)...we will compete more with
v3 as this is one of their key extension they did with Grizzly (LOL)


Also,

> there does not seem a way for the Grizzlet to be invoked as with the
> standard GrizzletAdapter.
>
>
>> Next is to create a CometHandler who can be invoked everytime the
>> cometd CometContext is updated:
>>
>>> CometHandler cometdListenerHandler = new CometHandler(){
>>> ....
>>> }
>>> CometEngine.getEngine().getCometContext("/cometd").addCometHandler(cometdListenerHandler);
>>>
>>
>
> [ZAID] If I understand correctly, this new CometHandler is simply for my
> app to process the JSON messages since the BayeuxCometHandler is doing
> the protocol work. The CometHandler takes the place of Grizzlets in
> non-Cometd code. Is this correct?

Correct. Grizzlet are just simplifying/hiding the complexity of Grizzly
Comet. Grizzlet make it simple, but under the hood they are build on top
of Grizzly Comet (like Cometd). So you have the choice of using Grizzly
Comet, Grizzlet and Grizzly Continuation. By definition,

Grizzly Comet supports
----------------------
+ Asynchronous Content Handler (async read and write)
+ Suspendable Requests (suspend/resume a request)
+ Container managed server push

Grizzlet support
-----------------
+ Suspendable Requests
+ Container Managed Server Push

Grizzly Continuation
---------------------
+ Suspendable Requests


Continuation/cometd/Grizzlet build on top of Grizzly Comet, which in
turn build on top of Grizzly Asynchronous Request Processing (this is
the foundation of Project Open ESB BTW). You can find more information
about Comet/Continuation/Grizzlet here:

http://weblogs.java.net/blog/jfarcand/archive/2008/01/slides_to_my_re.html

>
>
> 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?


>
>
>> So on every bayeux requests, the cometdListenerHandlsr.onEvent() will
>> be invoked, containing the JSON message. You can parse the message and
>> do something with it, like notifying other CometContext (ex:
>> /comet_80) by invoking:
>>
>>> CometEngine.getEngine().getCometContext("/comet_80").notify(JSON_parsed_message);
>>>
>
> [ZAID] I haven't gotten this far but I'm hopeful :-)

Let's fix the cometd problem first :-)

Thanks

-- jeanfrancois

>
>
>>>
>>
>> By doing that, your Comet clients will be able to notified by Cometd
>> clients.
>>
>> Does it make sense?
>>
>> Thanks!
>>
>> -- Jeanfrancois
>>
>>
>>
>>
>>
>>
>>>>
>>>> A+
>>>>
>>>> -- Jeanfrancois
>>>>
>>>>
>>>>> continued thanks.
>>>>> --Zaid
>>>>> http://altmobile.com
>>>>> On Jan 15, 2008, at 10:16 PM, Jeanfrancois Arcand wrote:
>>>>>>
>>>>>>
>>>>>> Jeanfrancois Arcand wrote:
>>>>>>> Hi,
>>>>>>> ALT Mobile DEV wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm running multiple servers in the same JVM where each server
>>>>>>>> is associated with a different instance of the same Grizllet
>>>>>>>> class. Each server of course is bound to a different port.
>>>>>>>>
>>>>>>>> Confusingly, the unique content from each Grizzlet is pushed to
>>>>>>>> all clients irrespective of the server:port they are connected.
>>>>>>> Yes :-( I didn't expected that Grizzly will be used like you just
>>>>>>> explained. Mainly, since Grizzly build on top of Grizzly Comet,
>>>>>>> the CometHandler I did for Grizzly is registered as '/comet'.
>>>>>>> Since there is only one CometEngine (this is a singleton), all
>>>>>>> Grizzlet will be invoked when the Grizzly Comet do a push, as
>>>>>>> internally it will do:
>>>>>>
>>>>>> Should have read:
>>>>>>
>>>>>> > Yes :-( I didn't expected that GrizzLET will be used like you just
>>>>>> > explained. Mainly, since GrizzLET build on top of Grizzly Comet,
>>>>>> the
>>>>>> > CometHandler I did for GrizzLET is registered as '/comet'. Since
>>>>>> there is
>>>>>> > only one CometEngine (this is a singleton), all Grizzlets will
>>>>>> be invoked
>>>>>> > when the Grizzly Comet do a push, as internally it will do:
>>>>>>
>>>>>> Its Grizzlet that build on top of Grizzly Comet, nor Grizzly :-)
>>>>>>
>>>>>> A+
>>>>>>
>>>>>> --jeanfrancois
>>>>>>
>>>>>>
>>>>>>
>>>>>>> cometContext.notify(...);
>>>>>>> and the cometContext is bind to 'comet'.
>>>>>>>>
>>>>>>>> It seems that the AsyncConnection is shared across all Grizzlets
>>>>>>>> and servers.
>>>>>>>>
>>>>>>>> I was expecting that:
>>>>>>>>
>>>>>>>> Grizzly server = unique port + unique Grizzlet instance + unique
>>>>>>>> comet context.
>>>>>>> OK I've just added a new API to let you customize the
>>>>>>> cometContextName. When you initialize the GrizzlyAdapter, just
>>>>>>> pass the name of the cometContext you want to use. In your case,
>>>>>>> it can be the just the port like the following:
>>>>>>>>  113         AsyncHandler asyncHandler = new DefaultAsyncHandler();
>>>>>>>>  114         asyncHandler.addAsyncFilter(new CometAsyncFilter());
>>>>>>>>  115         selectorThread.setAsyncHandler(asyncHandler);
>>>>>>>>  116     117     118         GrizzletAdapter adapter = new
>>>>>>>> GrizzletAdapter(String.valueOf(port));
>>>>>>>>  119         selectorThread.setAdapter(adapter);
>>>>>>>>  120         Grizzlet grizzlet =
>>>>>>>> (Grizzlet)loadInstance(grizzletClassName);
>>>>>>>>  121
>>>>>>> Try it and let me know if that works :-) I've uploaded the new
>>>>>>> artifacts to the m2 repository, or you can rebuild the comet
>>>>>>> module to get the changes.
>>>>>>> Thanks
>>>>>>> -- Jeanfrancois
>>>>>>>>
>>>>>>>>
>>>>>>>> thanks for any help.
>>>>>>>>
>>>>>>>>
>>>>>>>> --Zaid
>>>>>>>>
>>>>>>>> http://altmobile.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Bayeux Comet example with Grizzlets [was: Re: [Q] Grizzlets update clients connected to different servers]

ALT Mobile DEV
Hi... comments are embedded. much thanks.

--Zaid

http:/altmobile.com


On Jan 18, 2008, at 11:00 AM, Jeanfrancois Arcand wrote:

>
>
> ALT Mobile DEV wrote:
>> Hi, I've embedded a few more questions... thanks for your continued  
>> help.
>> --Zaid
>> http://altmobile.com
>> On Jan 17, 2008, at 11:28 AM, Jeanfrancois Arcand wrote:
>>>
>>>
>>> ALT Mobile DEV wrote:
>>>> Hi and thank you for all the help.
>>>> My response is embedded below.
>>>> --Zaid
>>>> http://altmobile.com
>>>> On Jan 16, 2008, at 11:46 AM, Jeanfrancois Arcand wrote:
>>>>>
>>>>>
>>>>> ALT Mobile DEV wrote:
>>>>>> as expected... perfect :-)
>>>>>
>>>>> Thanks
>>>>>
>>>>>> Do you have a Bayeux Comet example with Grizzlets?
>>>>>
>>>>> Since cometd is a client side technology, you don't need to  
>>>>> write any Grizzlet as by default, a cometd client will work with  
>>>>> any web server that support the bayeux protocol (JSON based).  
>>>>> Take a look at the following blog for a client examples
>>>>>
>>>>> http://weblogs.java.net/blog/jfarcand/archive/2007/11/finally_grizzly.html
>>>>>
>>>>> the way it works is the DOJO client is sending http request, and  
>>>>> the request body take the form of a JSON message. On the server  
>>>>> side, Grizzly Cometd implementation receive the request, decode  
>>>>> the JSON message and execute the proper operation. Like I've  
>>>>> said, any web server that understand bayeux will be able to  
>>>>> decode the message.
>>>> [ZAID] yes, I used the blog as a reference for our current  
>>>> Grizzlet implementation but it was not obvious to me how is the  
>>>> channel/operation exposed to the Grizzlet:
>>>> [72] String action = req.getParameterValues("action")[0];
>>>> [73] String name = req.getParameterValues("name")[0];
>>>> Our current implementation of the Dynamic Mashup Server runs 1  
>>>> mash-up on each Grizzly server which is connected to the Web 2.0  
>>>> containers. That architecture works well for consumer mash-ups.  
>>>> An alternative use case is found in enterprise dashboard-style  
>>>> mash-ups where the AJAX browser client wants to display multiple  
>>>> mash-ups on the same page.  For example, a GlassFish dashboard  
>>>> could display the compilation status/bug list of each GlassFish  
>>>> component. So that's 10+ mash-ups where each mash-up aggregates 2  
>>>> remote HTTP calls: 1 for the bug list and another for the  
>>>> continues integration stuff.
>>>> If a Cometd/Bayeux client can request multiple channels/
>>>> operations to the server (port, Grizzly server, Grizzlet, Web 2.0  
>>>> container) then that's the bees knees since we can selectively  
>>>> update specific aspects of this meta mash-up client.
>>>>>
>>>>>
>>>>> Now you might want to have client that aren't supporting bayeux  
>>>>> (they *don't* encode the request body using JSON) to be able to  
>>>>> interact with the cometd 'channel' (be able to update bayeux  
>>>>> clients). To do that, you  can use Grizzly Comet or Grizzlet to  
>>>>> get notification (or to push) data to those client. Before I go  
>>>>> into the details, are you planning to use Comet *and* Cometd  
>>>>> client (and do they have to interact each other via Grizzy Comet  
>>>>> or Cometd)?
>>>>>
>>>> [ZAID] yes, with your help :-)
>>>>> If yes, get ready to get a long email explaining how to do  
>>>>> it :-) :-)
>>>
>>> OK thank for the explanation. So what you need to do is to share  
>>> information between CometContext(s). One of your CometContext will  
>>> be the one registered with '/cometd', which is the one that  
>>> support the bayeux protocol. The first steps for you will consist  
>>> of bootstrapping the cometd implementation inside your Java  
>>> startup classes
>>>
>>>>   109         selectorThread.setWebAppRootPath(folder);
>>>>   110     111         String adapterClass =  
>>>> System.getProperty(ADAPTER);
>>>>   112         Adapter adapter;
>>>>   113         if (adapterClass == null){
>>>>   114             adapter = new CometdAdapter();
>>>>   115         } else {
>>>>   116             adapter = (Adapter)loadInstance(adapterClass);
>>>>   117         }
>>>
>> [ZAID] I assume that I do _not_ need to  create a new subclass of  
>> StaticResourcesAdapter since CometdAdapter registers the  
>> CometContext correctly. But, I must create a separate  
>> SelectorThread for the Bayeux clients and therefore open another  
>> port , since there is a 1:1 relationship in Grizzly 1.7 between  
>> SelectorThread and Adapter.
>
> Exact. Multi-Adapter support is right now supported in GlassFish v3.  
> Having our own in Grizzly can be a good idea as well, but require  
> more work as you need to map the request with the proper adapter. I  
> can take a look if you need it and help testing :-)...we will  
> compete more with v3 as this is one of their key extension they did  
> with Grizzly (LOL)
>
>

[ZAID] for our first release of the Dynamic Mashup Server, it'll be ok  
to run separate ports for the Comet and Cometd clients. So it's not an  
urgent requirement.


> Also,
>> there does not seem a way for the Grizzlet to be invoked as with  
>> the standard GrizzletAdapter.
>>> Next is to create a CometHandler who can be invoked everytime the  
>>> cometd CometContext is updated:
>>>
>>>> CometHandler cometdListenerHandler = new CometHandler(){
>>>> ....
>>>> }
>>>> CometEngine.getEngine().getCometContext("/
>>>> cometd").addCometHandler(cometdListenerHandler);
>>>
>> [ZAID] If I understand correctly, this new CometHandler is simply  
>> for my app to process the JSON messages since the  
>> BayeuxCometHandler is doing the protocol work. The CometHandler  
>> takes the place of Grizzlets in non-Cometd code. Is this correct?
>
> Correct. Grizzlet are just simplifying/hiding the complexity of  
> Grizzly Comet. Grizzlet make it simple, but under the hood they are  
> build on top of Grizzly Comet (like Cometd). So you have the choice  
> of using Grizzly Comet, Grizzlet and Grizzly Continuation. By  
> definition,
>
> Grizzly Comet supports
> ----------------------
> + Asynchronous Content Handler (async read and write)
> + Suspendable Requests (suspend/resume a request)
> + Container managed server push
>
> Grizzlet support
> -----------------
> + Suspendable Requests
> + Container Managed Server Push
>
> Grizzly Continuation
> ---------------------
> + Suspendable Requests
>
>
> Continuation/cometd/Grizzlet build on top of Grizzly Comet, which in  
> turn build on top of Grizzly Asynchronous Request Processing (this  
> is the foundation of Project Open ESB BTW). You can find more  
> information about Comet/Continuation/Grizzlet here:
>
> http://weblogs.java.net/blog/jfarcand/archive/2008/01/slides_to_my_re.html
>
>> 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?
>
>

[ZAID] yes, it's from Jan 16  and it uses your modifications to  
GrizzletAdaptor's constructor. Here's an HTTP Monitor screen shot of  
the traffic... it GET's the index.html and then does a POST for the  
handshake:

http://altmobile.com/images/grizzly_test/1.png

and here's the web page from the glassfish chat example:

http://altmobile.com/images/grizzly_test/2.png


I'll try to Google for a simpler dojo example but I just wanted to  
ensure that my CometHandler was properly installed... but the  
handshake seems to fail.



>>> So on every bayeux requests, the cometdListenerHandlsr.onEvent()  
>>> will be invoked, containing the JSON message. You can parse the  
>>> message and do something with it, like notifying other  
>>> CometContext (ex: /comet_80) by invoking:
>>>
>>>> CometEngine.getEngine().getCometContext("/
>>>> comet_80").notify(JSON_parsed_message);
>> [ZAID] I haven't gotten this far but I'm hopeful :-)
>
> Let's fix the cometd problem first :-)
>
> Thanks
>
> -- jeanfrancois
>
>>>>
>>>
>>> By doing that, your Comet clients will be able to notified by  
>>> Cometd clients.
>>>
>>> Does it make sense?
>>>
>>> Thanks!
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>
>>>
>>>
>>>
>>>>>
>>>>> A+
>>>>>
>>>>> -- Jeanfrancois
>>>>>
>>>>>
>>>>>> continued thanks.
>>>>>> --Zaid
>>>>>> http://altmobile.com
>>>>>> On Jan 15, 2008, at 10:16 PM, Jeanfrancois Arcand wrote:
>>>>>>>
>>>>>>>
>>>>>>> Jeanfrancois Arcand wrote:
>>>>>>>> Hi,
>>>>>>>> ALT Mobile DEV wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'm running multiple servers in the same JVM where each  
>>>>>>>>> server is associated with a different instance of the same  
>>>>>>>>> Grizllet class. Each server of course is bound to a  
>>>>>>>>> different port.
>>>>>>>>>
>>>>>>>>> Confusingly, the unique content from each Grizzlet is pushed  
>>>>>>>>> to all clients irrespective of the server:port they are  
>>>>>>>>> connected.
>>>>>>>> Yes :-( I didn't expected that Grizzly will be used like you  
>>>>>>>> just explained. Mainly, since Grizzly build on top of Grizzly  
>>>>>>>> Comet, the CometHandler I did for Grizzly is registered as '/
>>>>>>>> comet'. Since there is only one CometEngine (this is a  
>>>>>>>> singleton), all Grizzlet will be invoked when the Grizzly  
>>>>>>>> Comet do a push, as internally it will do:
>>>>>>>
>>>>>>> Should have read:
>>>>>>>
>>>>>>> > Yes :-( I didn't expected that GrizzLET will be used like  
>>>>>>> you just
>>>>>>> > explained. Mainly, since GrizzLET build on top of Grizzly  
>>>>>>> Comet, the
>>>>>>> > CometHandler I did for GrizzLET is registered as '/comet'.  
>>>>>>> Since there is
>>>>>>> > only one CometEngine (this is a singleton), all Grizzlets  
>>>>>>> will be invoked
>>>>>>> > when the Grizzly Comet do a push, as internally it will do:
>>>>>>>
>>>>>>> Its Grizzlet that build on top of Grizzly Comet, nor Grizzly :-)
>>>>>>>
>>>>>>> A+
>>>>>>>
>>>>>>> --jeanfrancois
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> cometContext.notify(...);
>>>>>>>> and the cometContext is bind to 'comet'.
>>>>>>>>>
>>>>>>>>> It seems that the AsyncConnection is shared across all  
>>>>>>>>> Grizzlets and servers.
>>>>>>>>>
>>>>>>>>> I was expecting that:
>>>>>>>>>
>>>>>>>>> Grizzly server = unique port + unique Grizzlet instance +  
>>>>>>>>> unique comet context.
>>>>>>>> OK I've just added a new API to let you customize the  
>>>>>>>> cometContextName. When you initialize the GrizzlyAdapter,  
>>>>>>>> just pass the name of the cometContext you want to use. In  
>>>>>>>> your case, it can be the just the port like the following:
>>>>>>>>> 113         AsyncHandler asyncHandler = new  
>>>>>>>>> DefaultAsyncHandler();
>>>>>>>>> 114         asyncHandler.addAsyncFilter(new  
>>>>>>>>> CometAsyncFilter());
>>>>>>>>> 115         selectorThread.setAsyncHandler(asyncHandler);
>>>>>>>>> 116     117     118         GrizzletAdapter adapter = new  
>>>>>>>>> GrizzletAdapter(String.valueOf(port));
>>>>>>>>> 119         selectorThread.setAdapter(adapter);
>>>>>>>>> 120         Grizzlet grizzlet =  
>>>>>>>>> (Grizzlet)loadInstance(grizzletClassName);
>>>>>>>>> 121
>>>>>>>> Try it and let me know if that works :-) I've uploaded the  
>>>>>>>> new artifacts to the m2 repository, or you can rebuild the  
>>>>>>>> comet module to get the changes.
>>>>>>>> Thanks
>>>>>>>> -- Jeanfrancois
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> thanks for any help.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --Zaid
>>>>>>>>>
>>>>>>>>> http://altmobile.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: users-
>>>>>>>> [hidden email]
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Bayeux Comet example with Grizzlets [was: Re: [Q] Grizzlets update clients connected to different servers]

Shing Wai Chan
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Bayeux Comet example with Grizzlets [was: Re: [Q] Grizzlets update clients connected to different servers]

ALT Mobile DEV
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 <[hidden email]>  
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Bayeux Comet example with Grizzlets [was: Re: [Q] Grizzlets update clients connected to different servers]

ALT Mobile DEV
Hi,

the ClassCastException was due to using an older version of Dojo.

thanks.


--Zaid

http://altmobile.com/Home.html



On Jan 18, 2008, at 8:08 PM, 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 <[hidden email]>  
> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Bayeux Comet example with Grizzlets [was: Re: [Q] Grizzlets update clients connected to different servers]

Jeanfrancois Arcand-2
In reply to this post by ALT Mobile DEV
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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Bayeux Comet example with Grizzlets [was: Re: [Q] Grizzlets update clients connected to different servers]

Jeanfrancois Arcand-2
In reply to this post by ALT Mobile DEV
Hi,

ALT Mobile DEV wrote:
> Hi,
>
> the ClassCastException was due to using an older version of Dojo.

I've guessed correctly :-) We still need to fix that on our side :-)

A+

-- jeanfrancois

>
> thanks.
>
>
> --Zaid
>
> http://altmobile.com/Home.html
>
>
>
> On Jan 18, 2008, at 8:08 PM, 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 <[hidden email]>
>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Bayeux Comet example with Grizzlets [was: Re: [Q] Grizzlets update clients connected to different servers]

ALT Mobile DEV
In reply to this post by Jeanfrancois Arcand-2
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-
>> [hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Q] Bayeux Comet example with Grizzlets [was: Re: [Q] Grizzlets update clients connected to different servers]

Jeanfrancois Arcand-2
Salut,

ALT Mobile DEV wrote:
> 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.

Agree. I will work on a new one :-)

>
> Or maybe the community should create a bundle with some working examples
> since all internet examples seem to be using a specific Jetty bundle.

The jetty left over from the example need to be removed. We also need to
maintains those examples in a better fashion...

> We'll be doing that as part of our commercial Web 2.0 tools in our next
> release in any event.

:-) This is great.


>
> 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
>         }
>     );
> ...

Not sure you can blog about it, but that would be good :-)

>
>
> 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.

OK I'm developing on tiger, but can also test on Leopard to see what I
can get.


>
>
> 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) ?

Yes. BTW I've made it configurable like we already discussed
(CometdAdapter.setContextPath(...));

and how is the channel related to the
> context?

This is the requests that will be mapped by the cometd engine. Any other
requests will be rejected, unless they are static resources.

It seems that the handshake occurs as long as the ip:port is
> correct.

Right. You can now configure it the way you did it for comet, e.g.
/cometd_port or something like that.

Thanks,

-- Jeanfrancois

>
> 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 <[hidden email]>
>>> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]