Re: geronimo-web.xml, container-config, container-specific namespaces
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-classloaderfalse/context-priority-classloader session-managerorg.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-classloaderfalse/context-priority-classloader managerWADI/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
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-classloaderfalse/context-priority-classloader session-managerorg.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-classloaderfalse/context-priority-classloader managerWADI/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
Re: [wadi-dev] Re: geronimo-web.xml, container-config, container-specific namespaces
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-classloaderfalse/context-priority-classloader
session-managerorg.codehaus.wadi.jetty5.JettyManager/session-manager
Re: geronimo-web.xml, container-config, container-specific namespaces
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
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
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
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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
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-classloaderfalse/context-priority-classloader session-managerorg.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-classloaderfalse/context-priority-classloader managerWADI/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
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-classloaderfalse/context-priority-classloader session-managerorg.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-classloaderfalse/context-priority-classloader managerWADI/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
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 [EMAIL PROTECTED] 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-classloaderfalse/context-priority-classloader session-managerorg.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-classloaderfalse/context-priority-classloader managerWADI/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
Re: geronimo-web.xml, container-config, container-specific namespaces
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 [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-classloaderfalse/context-priority-classloader session-managerorg.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-classloaderfalse/context-priority-classloader managerWADI/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,
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
