geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <>
Subject Re: WebContainers and WebConnectors
Date Sun, 10 Aug 2003 00:41:18 GMT

Aaron Mulder wrote:
> 	I'm not sure I believe that the web connectors should be 
> "configuration only".  If the WebContainer interface has a method for 
> handleRequest(InputStream, OutputStream) or something like that, then any 
> effort spent on optimizing the threading, networking, and associated 
> configuration of Geronimo will not be lost by switching between Tomcat and 
> Jetty (or whatever).  

I think that if we were starting from a clean slate for the webcontainers,
then such an approach could be considered.

But tomcat, jetty, etc. already have very close coupling between their
connectors and their containers - where lots of effort has been put into
making it fast, efficient, etc. etc.

I don't think at this stage that it is worthwhile us trying to
insert geronimo code between the actual connector and the actual

Thus I have proposed that the WebConnector services at this stage
a really just lifecycle and configuration managers for the real
connectors.  JMX is more that suitable for a WebConnector service to
talk to it's real connector instance.

But nothing in this design prevents WebConnectors and WebContainers
from eventually being implemented as you describe.   I see it as an
implementation detail that we will only be passing over configuration.

The important thing is to establish the connector lifecycle and configuration
as something managed by geronimo (and not managed by the implementation
of the webcontainer).

If the geronimo bus eventually does support passing streams etc. then we
could move to implementation of a shared connector thread pool etc
that would work with any container. However, in the short term - I would
see that needing much more work to change tomcat/jetty/etc.


> Likewise, more code could be shared between the 
> handling/processing of network EJB requests and network HTTP requests.
> 	As far as applications go, again I think there ought to be some 
> sort of external deployer, which can handle EARs, and then dispatch some 
> logical representation of a WAR to the web container "deploy(ClassLoader 
> content, URL[] dds)" or whatever.
> 	Now some of this may rely on being able to get a direct reference 
> from one container to the interface of another container "as JMX is not 
> really the right sort of bus to push HTTP requests/responses over", and if 
> JMX doesn't allow that, then IMHO that's a strike against using JMX as the 
> container infrastructure, but that's a different thread.  :)
> Aaron
> On Sat, 9 Aug 2003, Greg Wilkins wrote:
>>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
>>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
>>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.

Greg Wilkins<>             Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK.

View raw message