geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: WebContainers and WebConnectors
Date Sat, 09 Aug 2003 09:07:54 GMT
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
> 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. 

why not have the webconnector handshake with the webcontainer e.g. 
through JMX then JNDI, to get hold of an object ref, then implement the 
webconnector and hook directly to the webcontainer ? Since there is an 
explicit dep between 'nector and 'tainer, if the 'tainers ref is 
invalidated through reloading/deployment, the 'nectors will also be 
reloaded/deployed around the 'tainer, rehandshaking and gettting a new, 
valid object ref...

I don't like the idea of an empty 'nector, just there as a placeholder...

I was thinking about low and high bandwidth APIs between Geronimo 
components and came to the conclusion that the loose coupling provided 
by JMX was only suitable, as you imply, for low bandwidth relationships 
(debatable?), or high bandwidth ones where the use of JMX confers some 
worthwhile advantage (as in ANOther AppServer). Intercomponent 
high-bandwidth APIs will exist, you have just pointed one out, and I 
have come across them in stuff that I have worked on. One puts a ref in 
JNDI, the other takes it out locally and uses it.... The only problem 
occurs when you want to redeploy the former, but that is taken care of 
as described above.

This sort of thing should be documented along with component lifecycle etc.

>    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?). 

we need to decide whether this sort of fnality is a responsiblity of the 
'nector or lb - whichever it  is, they should be closely coupled. I have 
a plan, but that comes under clustering, which I have not opened up on 
yet to preserve bandwidth. But, I think I have the utimate resolution 
for a self-partitioning, replication strategy for the 'tainer, with 
fully integrated mod_jk[2]. The lb would be completely configured by the 
cluster and would need no manual configuration. That's another story 
that I can digress into if anyone is interested.

>  + 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.

gezza :-)

You're not trying to sneak in a bit of your own nomenclature there are you ?

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

another sneaky insertion ?

> 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.

I look forward to seeing it - does that mean I am excused and can put my 
energies elsewhere ?


> cheers

 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)

View raw message