geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <gr...@mortbay.com>
Subject WebContainers and WebConnectors
Date Sat, 09 Aug 2003 07:14:29 GMT

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<gregw@mortbay.com>             Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK.          http://www.mortbay.com


Mime
View raw message