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