geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bartel <j...@mortbay.com>
Subject Re: HELP! Need ideas for Geronimo presentation at ApacheCon!
Date Thu, 09 Oct 2003 14:06:14 GMT
I think Greg has explained the gist of the geronimo web container 
architecture quite well, so only a few comments inline ....

Jan
>> GW>The webcontainer AND ALL ITS components are being added as first class
>> GW>geronimo services.  Thus connecters, webapps, request logs (and 
>> eventually
>> GW>session managers, realms etc.) are all geronimo services with standard
>> GW>geronimo lifecycles, management and configuration.
>>
>> I wasn't aware of this feature set within Geronimo. Please elaborate
>> on how this is being acheieved. I'm not looking for JBo$$ bashing, I'm
>> simply looking for a down to earth description of the implmentation as
>> well as why this is significant (i.e. what can be achieved with this
>> level of integration?).
> 
> 
> I wrote up a little bit about this initially on the wiki :
>   http://wiki.codehaus.org/geronimo/Architecture/WebContainer
> 
> But I think that is already a little old and I need to update it.
> 
> Jan has done most of the work, so I'll let her give you the low down
> detail on this.   But the short summary is that all the webcontainer
> components are being wrapped as JSR77 managed objects and are deployed,
> configured and managed as any other G service.
> 
> Currently the webcontainer Jan has checked in has all the components
> defined in the same jetty-service.xml file.  But it is trivial to
> break out each subservice into it's own XXX-service.xml if you want to
> have multiple connectors or different deployment lifecycles.
As Greg says, the intention is that all major web container components 
are configured as first-class geronimo services. Thus the container 
itself, port/s to listen on for http requests, an access log, an http 
session manager etc are all configured using standard geronimo syntax in 
standard geronimo service configuration files, not in arcane 
container-specific config files bolted on.

Because these are standard geronimo services, they can all be hot 
deployed - drop a web container config file into the hot deploy 
directory and the web container starts accepting web apps to deploy; 
drop a/another web connector config file into the hot deploy directory 
and webapps can be served from the specified port; drop the access log 
config file in and you have a log of http requests.

As they are all geronimo services, each has the standard geronimo/jsr77 
lifecycle. Thus it is possible to stop just one of the web connectors 
without stopping the whole container. Conversely, because we've 
implemented a containment relationship between these components and the 
web container, stopping the container will automatically stop the 
connectors, logs etc.

Additionally, as all of these web components are mbeans, they can be 
managed via the geronimo jmx console.

>> GW>The web tier is a major component of an app server and it should not
>> GW>be treated as a foreign subsystem simply because it is too much work
>> GW>to re-implement.
>> GW>
>> GW>I think that is going to be a huge plus for Geronimo and allow
>> GW>people to develop web-centric services (like HttpSesson distribution)
>> GW>using geronimo's infrastructure without getting into jetty or tomcat
>> GW>internals - well that's the idea anyway.
>>
>> I'd really like to have a real world application of this functionality,
>> possibly along the lines of what you describe above. I need to be able
>> to explain and possbily discuss this stuff at ApacheCon (although I'm
>> going to rely on other Geronimo developers who are attending to jump
>> into the fray as needed ;-)).
> 
> 
> 
> I think distributed sessions is a good example - for which Jules is the
> best person to give you detail.  But I'll summaries.
> 
> There are many issues to consider with distributed sessions and the bad
> specification means that we are unlikely to have a one-size-fits-all
> distributed session manager.
> 
> As it is, both tomcat and jetty have pluggable session manager and multiple
> implementations.    These session managers commonly use some, a bit or a 
> lot
> of the app server infrastructure (eg there are some written directly to
> javagroups, others to jboss services, and other to use EJBs).   We are 
> aiming
> to achieve pluggable session managers in geronimo that will provide similar
> (and other) implementations.  We aim to be able to write these services 
> without
> any dependancy on jetty and/or tomcat code.
> 
> cheers
> 
> /****************************************************************
> * www.coredevelopers.net for Open Source training & support.
> * Training: J2EE Web/Cluster London Nov 10-13
> * --
> * Greg Wilkins
> * Partner
> * Core Developers Network
> ****************************************************************/
> 



Mime
View raw message