Jan
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.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.
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 ****************************************************************/
