dev@grizzly.java.net

Re: Upcoming features for Grizzly? Time to speak!

From: charlie hunt <charlie.hunt_at_sun.com>
Date: Wed, 19 Sep 2007 09:02:15 -0500

It does not matter much to me exactly how it is implemented. ;-)

The thing I would like to (easily) be able to do is the task of setting
up a Grizzly transport configuration, (i.e. have a class that holds that
information), then give that transport configuration to another class,
(perhaps the Controller), and be able to manage the starting, stopping,
pausing and resuming of the Grizzly based application.

For simplicity, a default Grizzly transport configuration which would be
the most commonly used transport configuration could be made available
so that all one has to do is give that default transport configuration
to the class that manages the start, stop, pause and resume, (perhaps
give it to the Controller).

charlie ...

Jeanfrancois Arcand wrote:
> Salut,
>
> [continung the discussion on dev list]
>
> charlie hunt wrote:
>> How about adding something like a TransportConfiguration for Grizzly
>> that would allow one to easily configure Grizzly? Perhaps even
>> provide a DefaultTransportConfiguration?
>>
>> And, also provide a TransportManager which could take a
>> TransportConfiguration and then be able to start, stop, pause and
>> resume Grizzly?
>>
>> What I am thinking is being able to do something like:
>>
>> TransportConfiguration tc =
>> TransportConfiguration.createNewConfiguration(); // factory method
>> tc.setHostName("localhost");
>> tc.setPort(12345);
>> tc.protocol(UDP);
>> ...
>> tc.set[other Grizzly configurables]();
>>
>> TransportManager tm = TransportManager.getTransportManager(tc);
>
> I think a TransportManager is alsmost the same as the current
> Controller. So we might ends up with:
>
> Controller c = ControllerManager.getTransportManager(tc);
>
> The name is not that good (ControllerManager).
>
>
>>
>> tm.start(); // start Grizzly
>>
>> // ... some time later decide to pause processing
>> tm.pause();
>> // do some re-configuration
>> tc.setPort(54321);
>> tc.setHostName("failover-guy");
>> // resume processing
>> tm.resume();
>
> Controller has those methods as well.
>
>>
>> If wanted to use the DefaultTransportConfiguration, one could easily do:
>>
>> TransportConfiguration tc =
>> TransportConfiguration.getDefaultConfiguration();
>> TransportManager tm = TransportManager.getTransportManager(tc);
>> // start my Grizzly application
>> tm.start();
>
> Looks good!
>
> -- Jeanfrancois
>
>>
>> charlie ...
>>
>> Jeanfrancois Arcand wrote:
>>> Hi,
>>>
>>> since this community is constantly growing, I would like to start a
>>> thread about what we should focus on for the next couple of months.
>>>
>>> I've got a lot of private requests from all around the world, and I
>>> think anybody interested to contribute would like to know what is
>>> requested. So feel free to add you own requests to the list. I will
>>> publish them, let say in two weeks, on our main site so new users
>>> that wants to becomes committers knows where to start.
>>>
>>> Here it is:
>>>
>>> + Improve documentations, which include back to back tutorials,
>>> blogs etc.
>>>
>>> + Asynchronous Http client support: We already have the tcp client
>>> and http server side support. Writing a client will requires more
>>> works but at least we already have the http parser available. This
>>> features have been requested several times by the openESB project
>>> and JavaFX.
>>>
>>> + Asynchronous Write Queue: That one is probably the more urgent one
>>> as it is clear we are missing that feature.
>>>
>>> + xSocket|Mina support: Those NIO Framework easily allow you to
>>> replace their NIO provider. I'm interested to support both of them
>>> for their easy to use, high level API.
>>>
>>> + Bayeux/cometd: The current implementation is not uptodate with the
>>> latest specs.
>>>
>>> + AsyncRead/Write support in Comet: This feature is already
>>> available in GlassFish v2 (Grizzly 1.0). We just need to ports it.
>>>
>>> + JRuby support: There is some missing features like adding your own
>>> jars to the classpath at startup, jdbc support, etc.
>>>
>>> + Grizzly Web Server: Right now Grizzly is quite simple to configure
>>> programmatically, but I would like to be able to configure it using
>>> a property file or better, with Spring.
>>>
>>> I need to dig more in my emails but that's a start :-) Feel free to
>>> add anything!
>>>
>>> Thanks
>>>
>>> -- Jeanfrancois
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>

-- 
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>