geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: WebContainers and WebConnectors
Date Sat, 09 Aug 2003 14:05:45 GMT
	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).  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.  :)


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

View raw message