Greg Wilkins wrote:
Aaron Mulder wrote:
Well... is it possible to make this not specific to WADI? Perhaps
make it a generic "clustering manager" tag, and is "just so happens"
that the only classes we let you configure so far are the WADI ones?
Ideally, we'd put some generic interface in the Geronimo space, and
then the WADI ones would implement or extend that, so if we ever
wanted to integrate other clustering options we'd leave that door
open.
+1
I really think that clustering contents of geronimo-web.xml needs to
be moved out of the webapplication. Clustering should be configured once
and only once for the whole server - not within each web application (also
we have to consider EJB clustering which does not have a webapp).
So I really see that we need a new module called "cluster" (or "wadi" if
we want to persist with the implementation exposure we have with
jetty and tomcat).
If the only web container specific part of the configuration is to
choose the class type of the session manager, then I think that this could
almost be hard coded in the jetty and tomcat modules - when they see
a distributable tag, they look for a cluster/wadi gbean and instantiate
a specific session manager that is required to work with it.
If there is other web app specific configuration, then it can be
left in a geronimo-web.xml, but hopefully as a non container specific
nature.
cheers
We are having a discussion about this on wadi-dev at the moment.
There are two approaches - per-app and per-server. Setting up clustering
in the geronimo-web.xml corresponds to the per-app approach. Perhaps we
could have an e.g. default-geronimo-web.xml in the server somewhere that
sets up a server wide configuration.
For the per-server model that you advocate, we need some way of allowing
webapps to 'own' their own session manager instance, whilst sharing
components between these session managers, such as distribution medium etc.
WADI has initially been very focussed on the per-app approach, as this
is currently the only way to shoe-horn it into the various containers
that it supports, so further thought is needed here.
I suggest that Geronimo will want to support both approaches and that we
come up with a framework that can do this, whilst pursuing the immediate
goal of a per-app solution and then later on pushing towards a
per-server based one.
Check out my other posting on this thread that advocates a
top-level-gbean approach, using the geronimo-web.xml to hook it into the
web-app context. Perhaps a SessionManagerFactoryGBean could be used on a
per-server basis to create individual SessionManagers (for each app)
that can then share further server-wide resources ?
Jules
--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."
/**********************************
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
* www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/
