Upcoming features for Grizzly? Time to speak!

[Jeanfrancois Arcand-2]

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@...
For additional commands, e-mail: dev-help@...

[charlie hunt-3]

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

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();

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();

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@...
> For additional commands, e-mail: dev-help@...
>

--

Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)

<http://java.sun.com/docs/performance/>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jeanfrancois Arcand-2]

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@...
>> For additional commands, e-mail: dev-help@...
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[charlie hunt-3]

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@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--

Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)

<http://java.sun.com/docs/performance/>


[charlie.hunt.vcf]

---

begin:vcard
fn:charlie hunt
n:hunt;charlie
email;internet:charlie.hunt@...
tel;work:x47708 or [phone]
x-mozilla-html:TRUE
version:2.1
end:vcard

---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...