Here is what I'm thinking about the geronimo web container.
I would like to see the container, the connectors and webapplications
as all top level geronimo components (aka services).
They would all have independant lifecycles - create, start, stop, destroy
that can be controlled by the normal container mechanisms - with the
exception that both connectors and webapps depend on having a container
deployed.
I would like to support multiple containers, so you can have isolated
collections of connectors and webapps (eg for security and/or admin)
The deployment would go something like as follows:
+ A webcontainer is deployed. This should have no
dependancies, but will lazily discover JNDI services etc as needed.
The container configuration would include such things as a default
web.xml to load for all webapps.
+ A webconnector is deployed. This will depend on a webcontainer
being deployed. The exact way one of multiple containers is
selected is yet to be determined - but there will be a default
method, plus an option to be specific in the configuration.
The configuration of the web connector will contain many common
parameters:
protocol name - http, https, ajp, etc.
port - to listen on
interface - optional interface to listen on
max connection.
max idle persistance time.
required contexts - names of contexts that must be registered and
started with container before the connector accepts
any connections.
But it will also need to allow configuration for connector specific
parameters. I assume this can be done by a getInitParameter style
map - but maybe something more typed or verifiable can be used - I'll
wait and see how the service configuraton mechanism develops.
I don't expect the webconnector service to actually implement the
connector - as JMX is not really the right sort of bus to push HTTP
requests/responses over. Instead I see the webconnectors pushing their
configuration at the webcontainer - which will create the actual connector.
I would like to interpret the service lifecycle for a web connector so that
a stopped webapp can continue handling connections, but will not accept
any new connections. Only when it is destroyed will any existing connections
be terminated without due process. This could be extended to work
for sessions - ie a stopped connector would continue working for known
sessions, but would reject requests without sessions (for gentle
node in cluster shutdown - may not be required with mod_jk2?).
+ A webapplication is deployed. It also depends on a webcontainer
being deployed and will use the same mechanism as the webconnector to
locate a specific container.
A webapp should need no gerry specific configuration, but I would like
to provide that as an option. Specifically I would like to be able to
configure overrides of webapp initParams without opening up a war and
changing it's web.xml. Perhaps just a post web.xml to be applied after
the webapps own?
Again the webapplication service will not actually implement the
webapp container - but it will call a deploy method on the webcontainer
service. Ideally it would provide a pre-parsed DOM (or whatever
geronimo uses as standard in-memory xml tree) of the web.xml - to
try to prevent multiple parsings of that file. Any elements that
can be handled by the webapplication service will be handled (population
of JNDI context etc.)
I would like to interpret the service lifecycle for a webapp so that
a stopped webapp can continue handling requests, but will not accept
any new requests. Only when it is destroyed will any existing requests
be terminated without due process.
All of the above will of course provide jsr77 mbeans where appropriate.
All of the above is all implemented in gerry code. It is not a facade
to tomcat/jetty/orion/whatevers own lifecycle and jsr77 implementation.
I think that this approach will allow the vaste majority of the web tier
to be configured and deployed in gezza without any implementation specific
configuration/file/etc. being used.
For example, the webconnectors components - being only configuration and
lifecycle will be usable with any webcontainer implementation. They could
even contain initParams (or whatever) for multiple webcontainer
implementations.
I'll then be providing a Jetty implementation of the AbstractWebContainer -
but I hope that nobody will be able to tell what I have used (except by
it's reliable and scalable operation :-) Nobody will see any
love-then-or-hate-them jetty configuration files (unless it is adopted for
all of the big G-man :-)
I also think that eventually other sub-components of the web tier
should also be able to be made top level geronimo components/services.
The SessionManager could probably do with similar treatment - so that
session persistance, replication, statistics etc. etc. can be done as
a reusable geronimo component rather than as tomcat/jetty etc. specific
in implementation, configuration and behaviour.
I hope the get a skeleton of all this going in the next week or two.
cheers
--
Greg Wilkins<[EMAIL PROTECTED]> Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
