You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2005/10/31 03:45:02 UTC
geronimo-web.xml, container-config, container-specific namespaces
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
Re: geronimo-web.xml, container-config, container-specific namespaces
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Yeah, I was going to say, let's merge the manager and session-manager
elements from the 2 separate plans into a single session-manager
element in the geronimo-web plan. Though it looks like one takes a
class name and the other takes a GBean name, so we'd have to figure
that out. I assume that the combined element should take a class name
and then we can have a "delegating" implementation of that class that
references a GBean instead, but then we have to figure out which GBean
to point it to... And I also don't know what to say about the GBean
that you only want to start if the app runs in Tomcat (but is there a
reason not to include that GBean in a separate Tomcat or Tomcat
Clustering configuration instead of in the application itself?).
Jules, can you suggest what the common schema elements would look like
if we were going to put only one set of configuration information into
the generic geronimo-web.xml plan, and then have both Jetty and Tomcat
read the same configuration information from there?
Thanks,
Aaron
On 1/4/06, David Jencks <da...@yahoo.com> 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.
> > **********************************/
> >
>
>
Re: [wadi-dev] Re: geronimo-web.xml, container-config, container-specific
namespaces
Posted by Jules Gosnell <ju...@coredevelopers.net>.
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 <jg...@apache.org> 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.
**********************************/
Re: geronimo-web.xml, container-config, container-specific namespaces
Posted by Jules Gosnell <ju...@coredevelopers.net>.
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 <jg...@apache.org> 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.
**********************************/
Re: geronimo-web.xml, container-config, container-specific namespaces
Posted by Jeff Genender <jg...@apache.org>.
Aaron Mulder wrote:
> In my personal experience, any machine in a cluster is fully in a
> cluster -- I haven't seen something like 10 machines running 1
> clustered app and then each running something else on the side.
I can't agree...I may want to cluster my app, but I surely do not want
to cluster the console. I think there are various use cases that can be
applied here.
>
> However, it is kind of nice in WebLogic that you can deploy to either
> a cluster or a single machine. I would lean toward that kind of
> approach. You set up clustering at the server level, and then each
> application can either be deployed to individual servers or to the
> cluster, but if you don't set up clustering at the server level,
> there's no cluster to deploy to and you have to deploy to individual
> servers. (There's plumbing in our deployer so it could support that
> kind of approach.)
>
> Aaron
>
> On 1/5/06, Jeff Genender <jg...@apache.org> wrote:
>>
>> 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).
>> I don't agree on this point. You should be able to specify certain web
>> apps that need clustering and others that do not. IMHO, you should be
>> able to cluster the components that you want, and not turn it on for the
>> entire server. The Tomcat clustering works this way today. I can turn
>> on clustering at the Engine, host, or context level.
>>
>>> 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
>>>
>>>
>>>
Re: geronimo-web.xml, container-config, container-specific namespaces
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
In my personal experience, any machine in a cluster is fully in a
cluster -- I haven't seen something like 10 machines running 1
clustered app and then each running something else on the side.
However, it is kind of nice in WebLogic that you can deploy to either
a cluster or a single machine. I would lean toward that kind of
approach. You set up clustering at the server level, and then each
application can either be deployed to individual servers or to the
cluster, but if you don't set up clustering at the server level,
there's no cluster to deploy to and you have to deploy to individual
servers. (There's plumbing in our deployer so it could support that
kind of approach.)
Aaron
On 1/5/06, Jeff Genender <jg...@apache.org> wrote:
>
>
> 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).
>
> I don't agree on this point. You should be able to specify certain web
> apps that need clustering and others that do not. IMHO, you should be
> able to cluster the components that you want, and not turn it on for the
> entire server. The Tomcat clustering works this way today. I can turn
> on clustering at the Engine, host, or context level.
>
> >
> > 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
> >
> >
> >
>
Re: geronimo-web.xml, container-config, container-specific namespaces
Posted by Jeff Genender <jg...@apache.org>.
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).
I don't agree on this point. You should be able to specify certain web
apps that need clustering and others that do not. IMHO, you should be
able to cluster the components that you want, and not turn it on for the
entire server. The Tomcat clustering works this way today. I can turn
on clustering at the Engine, host, or context level.
>
> 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
>
>
>
Re: geronimo-web.xml, container-config, container-specific namespaces
Posted by Jules Gosnell <ju...@coredevelopers.net>.
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.
**********************************/
Re: geronimo-web.xml, container-config, container-specific namespaces
Posted by Greg Wilkins <gr...@mortbay.com>.
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
Re: geronimo-web.xml, container-config, container-specific namespaces
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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
On 1/4/06, Jeff Genender <jg...@apache.org> 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.
> >> **********************************/
> >>
>
Re: geronimo-web.xml, container-config, container-specific namespaces
Posted by Jeff Genender <jg...@apache.org>.
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.
>> **********************************/
>>
Re: geronimo-web.xml, container-config, container-specific namespaces
Posted by Jules Gosnell <ju...@coredevelopers.net>.
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).
I really feel that it is valuable for WADI-enabled apps to port easily
between Jetty and Tomcat (and hopefully other)-based containers.
I would be much happier with one proprietary dd or plan, than two. So, I
am still on course for somehow merging the two.
As to whether this dd/plan lives in or outside the deployable - I'm not
to worried. I imagine that WADI will ship its demo webapp with the dd
inside for self-containedness' sake, but I have no religious views on
the subject.
> 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?
I think some form of adjustment here will be the sensible way forward.
Thanks for the pointers,
Jules
>
> 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.
**********************************/
Re: geronimo-web.xml, container-config, container-specific namespaces
Posted by David Jencks <da...@yahoo.com>.
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.
> **********************************/
>
Re: geronimo-web.xml, container-config, container-specific namespaces
Posted by Jules Gosnell <ju...@coredevelopers.net>.
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.
**********************************/