After further thought...
I imagine it going like this:
container checks for the WEB-INF/web.xml/<distributable/> tag.
If it exists, container looks at the e.g.
geronimo-web.xml/<distributable-session-manager/> tag.
The value of this tag could be either an enum (e.g. {WADI,...}), a
classname or the name of some existing component (GBean) (any other ideas?)
I don't like the enum based solution - it just leads to more code and
documentation to ties the key to its value.
The classname version assumes a void ctor and a separate instance of the
class for each webapp (I think there may be a case for being able to
share a session manager across web contexts - but the jury is still out).
The GBean version delegates full control over the construction and
configuration to Geronimo whilst allowing the possibility of either
shared or individual session manager instances. I think that I would
prefer this route.
Ultimately, I might also like to see an e.g. <local-session-manager> tag
in the geronimo-web.xml as well, allowing the selection of session
managers in a non-distributable mode. WADI willl run in this mode, as do
other Tomcat session managers that might be selected via this mechanism
(I'm not sure whether the standalone mechanism for session manager
selection has been exposed for TC or not).
Thoughts ?
Jules
Jules Gosnell 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.
Thanks,
Aaron
This is a good idea but - The choice of WADI class passed in is
container specific. For Jetty you use a WADI class that implements the
Jetty Session Manager interface, for TC likewise. Jetty and TC Session
Managers do not implement a common interface. We could look at
defining a third interface - e.g. GeronimoWebSessionManager - but I
see no gain in that, since by implementing it, you do not guarantee
that your session manager will work in Jetty or TC. It just adds yet
more layers of abstraction.
WADI will soon be in the incubator and an integral part of Geronimo.
If we want to abstract anything between web session managers, I think
it should be done in WADI, as it is (Jetty and TC managers both wrap
and translate/delegate calls to a single WADI Manager interface).
How does that sound ?
Jules
On 1/4/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
Hi,
Actually...this is quite simple...
Use the generic web. Have a new tag...call it <wadi-cluster>, or
whatever.
Each of the container's builders can then have a flag set that is
passed
into its web context. The web context can then set its own
implementation...i.e. for Jetty, it then can create and apply its own
org.codehaus.wadi.jetty5.JettyManager and for Tomcat it can create and
apply its org.codehaus.wadi.tomcat55.TomcatManager. No need for GBeans
if WADI is to become a first class citizen. The Tomcat GBean is purely
for the ability to declaratively swap out managers.
Thus, this will allow for a single ability to set up a generic tag that
both containers can understand how to act upon.
Jeff
David Jencks wrote:
It is possible (I think) to do what you want, but I do not recommend
it. I would prefer that you use external plans, and write 2 new
modules
inside configs, to deploy your sample to jetty and to tomcat. Take
the
geronimo-web.xml out of the app and put it in src/plan/plan.xml.
However, if you wish to defy me :-) you can use the generic schema
http://geronimo.apache.org/xml/ns/j2ee/web-1.0 (geronimo-web-1.0.xsd)
with sections in a container-config for the jetty and tomcat specific
parts. These would use the namespace/schemas e.g.
http://geronimo.apache.org/xml/ns/web/jetty/config-1.0
(geronimo-jetty-config-1.0.xsd).
A problem with this approach might be that you are including a
gbean in
the tomcat config that is not needed in the jetty config. I don't
understand why this would be there anyway, but I don't think you can
have gbeans in the container-config part.
Is it possible to adjust the jetty and tomcat clustering configs to be
roughly the same and include the element in geronimo-web-1.0.xsd?
hope this helps
david jencks
On Jan 4, 2006, at 10:19 AM, Jules Gosnell wrote:
Aaron, David, or anyone in the know :-)
Maybe you can help me with this:
I have a WADI demo webapp.
To get it running with Jetty, I need a WEB-INF/geronimo-web.xml that
looks like this:
<web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.0";
configId="wadi">
<context-root>/wadi</context-root>
<context-priority-classloader>false</context-priority-classloader>
<session-manager>org.codehaus.wadi.jetty5.JettyManager</session-manager>
</web-app>
To get it running with Tomcat, I have to have a geronimo-web.xml that
looks like this:
<web-app
xmlns="http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0";
configId="wadi">
<context-root>/wadi</context-root>
<context-priority-classloader>false</context-priority-classloader>
<manager>WADI</manager>
<gbean name="WADI"
class="org.apache.geronimo.tomcat.cluster.WADIGBean"/>
</web-app>
What I would like, is a single geronimo-web.xml that contains both
Jetty and TC configs, merged.
Do you know if this is possible, if so, would you mind pointing me in
the right direction ?
Much appreciated,
Jules
Aaron Mulder wrote:
David J,
I thought when you added the separate Tomcat and Jetty
namespaces, you
were going to remove the container-config section from the generic
geronimo-web.xml, but it seems that it's still there. Jeff thinks
maybe it's for something like the console, where we want it to
work in
both Tomcat and Jetty yet we might still require some
container-specific extensions (makes sense to me).
If we're going to keep the generic geronimo-web.xml and keep the
container-config section in it, can we drop the container-specific
namespaces? I think you favored the namespaces because if you use a
container-specific namespace then any container-specific settings
could be validated in XML, but I think that's pretty useless if it
only applies if you're willing to force your app to only deploy
in one
container or the other. (That is to say, if you want your web
app to
run in either Tomcat or Jetty -- which is probably the normal case,
then you can't use a container-specific namespace so it doesn't
matter
what the benefits of container-specific namespaces are.)
The only way I can see the container-specific namespaces being
beneficial is if the container-config became an "any" and then we
namespaced the content that went within it -- so the overall file
always used the generic namespace but then you used a
container-specific one for the contents of the container-config
element only.
Am I missing something?
Thanks,
Aaron
--"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.
**********************************/
--
"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.
**********************************/
