Hi Charlie et al.
I had a few email exchange with Jeanfrancois the other day on the
recently released POJO comet,
with the following questions (and Jeanfrancois answered some of them):
>> 1. avoid setting the classloader to "lib" in GrizzletContainer - i.e.
>> let the user have the full control - i.e. via classpath
>Agree.
>> 2. to be completely WEB-container-less, it would be nice not to
>> specify the "apps" directly from GrizzletContainer. For the same
>> reason as the above, this seems to belong to "client application" -
>> not the Grizzlet api.
>How do we know where the apps is located?
WB: Somehow passed from the "application" layer? I feel that we will
never (or shouldn't)
provide a full web container support at the Grizzly level. Therefore, it
makes more sense
to take an all-or-nothing approach in designing the api. Same for
deployment/configration stuff ... IMHO.
>> 3. on the same thought, to extend the current API for more servlet
API
>> (2.4) parity, anything related to HTTP/URL processing, including
>> session/security, should be supported .. and the rest, i.e. web
>> container specific, is irrelevant.
> I agree and one thing we have to keep in mind is simplicity :-) Yes
that's my goal to support Servlet as well .. the Servlet EG are also
working on standardizing the Comet sutff
WB: I think there's a pretty unique goal here, i.e. a POJO comet engine.
And I would be very interested in hearing comments on the above
questions.. (as minutes :-) )
- Wenbo
-----Original Message-----
From: Charles.J.Hunt_at_sun.com [mailto:Charles.J.Hunt_at_sun.com] On Behalf
Of charlie hunt
Sent: Wednesday, October 03, 2007 9:52 AM
To: dev_at_grizzly.dev.java.net
Subject: Project Grizzly Meeting Agenda, Oct 3rd
Agenda:
1.) Grizzly 1.6.1 Vote
2.) Connection Caching tutorial review
3.) FindBugs plug-in working with NetBeans IDE 6.0 Beta1 (tutorial
update in the works)
4.) Additional features
5.) Open mic
Logistics:
Time: 10:00am PDT
Toll free: 866.839.8145
International: 865.524.6352
Access code: 1157051
charlie ...
--
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>