You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2005/08/22 22:49:44 UTC
Web container-specific configuration
After a lot of discussion about the virtual-host configuration, Aaron,
Jeff and I think that the best way to proceed is to have xml schemas
for container specific configuration and include the virtual host in
the container specific config. This will replace the current
name/property container specific config.
Why put the virtual host into container specific config? well, the
meaning of specifying "virtual-host" in jetty and tomcat are really
different. In tomcat this is a reference to a preconfigured list of
host + multiple aliases, and if will fail if the host is not already
configured. In jetty, this simply adds the VH string to some routing
code inside jetty. If we reused the same syntax for both containers,
you would get surprising results whenever you switched containers
unless you were very aware of the different meanings.
How will the proposed container specific config work? I'll add an any
element in the geronimo-web schema, and each builder will look for its
own namespace and interpret it as appropriate. This will allow one
plan to be deployed on multiple web containers.
comments?
thanks
david jencks
Re: Web container-specific configuration
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Mon, 22 Aug 2005, Jacek Laskowski wrote:
> It seems to be the simplest solution at the moment, so +1 for the idea.
> I'm definitely looking forward to seeing the change to figure out how
> exactly the namespace differentiation works. Is it already used
> elsewhere so I could look at it and experiment?
It should look something like this (where everything is
standard/generic except what you choose to put into the
"container-specific" element, bearing in mind that I don't know what
David is going to name the new eleemnts):
<web-app xmlns="http://geronimo.apache.org/xml/ns/web"
xmlns:naming="http://geronimo.apache.org/xml/ns/naming"
configId="MyWebApp">
<naming:ejb-ref>
<naming:ref-name>ejb/RemoteSession</naming:ref-name>
<naming:target-name>
geronimo.server:J2EEApplication=other-ear-name,
J2EEModule=other-ejbs.jar,J2EEServer=geronimo,
j2eeType=StatelessSessionBean,name=RemoteSession
</naming:target-name>
</naming:ejb-ref>
<container-specific>
<jetty-extension xmlns=".../jetty">
<some-jetty-setting ... />
</jetty-extension>
<tomcat-extension xmlns=".../tomcat">
<some-tomcat-setting ... />
</tomcat-extension>
</container-specific>
</web-app>
Re: Web container-specific configuration
Posted by Jacek Laskowski <jl...@apache.org>.
David Jencks wrote:
> There's something similar but considerably more generic in the
> service-builder for xml-attributes and xml-references
Does XmlBeans manage the stuff? What class/method should I be taking a
look at?
> Anyway, should be done fairly soon :-)
Excellent. I'm looking forward to looking at the source.
> david jencks
Jacek
Re: Web container-specific configuration
Posted by David Jencks <da...@yahoo.com>.
On Aug 22, 2005, at 1:59 PM, Jacek Laskowski wrote:
> David Jencks wrote:
>
>> How will the proposed container specific config work? I'll add an
>> any element in the geronimo-web schema, and each builder will look
>> for its own namespace and interpret it as appropriate. This will
>> allow one plan to be deployed on multiple web containers.
>
>> comments?
>
> It seems to be the simplest solution at the moment, so +1 for the
> idea. I'm definitely looking forward to seeing the change to figure
> out how exactly the namespace differentiation works. Is it already
> used elsewhere so I could look at it and experiment?
There's something similar but considerably more generic in the
service-builder for xml-attributes and xml-references
Anyway, should be done fairly soon :-)
thanks
david jencks
>
>> david jencks
>
> Jacek
>
Re: Web container-specific configuration
Posted by Jacek Laskowski <jl...@apache.org>.
David Jencks wrote:
> How will the proposed container specific config work? I'll add an any
> element in the geronimo-web schema, and each builder will look for its
> own namespace and interpret it as appropriate. This will allow one plan
> to be deployed on multiple web containers.
> comments?
It seems to be the simplest solution at the moment, so +1 for the idea.
I'm definitely looking forward to seeing the change to figure out how
exactly the namespace differentiation works. Is it already used
elsewhere so I could look at it and experiment?
> david jencks
Jacek
Re: Web container-specific configuration
Posted by David Jencks <da...@yahoo.com>.
On Aug 22, 2005, at 4:14 PM, Jeremy Boynes wrote:
> David Jencks wrote:
>> After a lot of discussion about the virtual-host configuration,
>> Aaron, Jeff and I think that the best way to proceed is to have xml
>> schemas for container specific configuration and include the virtual
>> host in the container specific config. This will replace the current
>> name/property container specific config.
>> Why put the virtual host into container specific config? well, the
>> meaning of specifying "virtual-host" in jetty and tomcat are really
>> different. In tomcat this is a reference to a preconfigured list of
>> host + multiple aliases, and if will fail if the host is not already
>> configured. In jetty, this simply adds the VH string to some routing
>> code inside jetty. If we reused the same syntax for both containers,
>> you would get surprising results whenever you switched containers
>> unless you were very aware of the different meanings.
>> How will the proposed container specific config work? I'll add an
>> any element in the geronimo-web schema, and each builder will look
>> for its own namespace and interpret it as appropriate. This will
>> allow one plan to be deployed on multiple web containers.
>> comments?
>
> I'd ask that we settle on something once and for all. This was changed
> once from container-specific to generic (breaking every existing
> plan), changed again to add in container-specific options, and now
> we're changing yet again having cut a release somewhere in the middle.
>
> Before rushing to implementation, can we please put some more
> consideration and discussion into up-front design.
Well, I've implemented it, and it works, which is more than the
existing code, so I plan to commit it, if only to give people something
concrete to argue against.
>
> On the technical front, I remain uncomfortable with a single generic
> namespace as there is no way for the deployment system to tell what
> the target container will be. If the plan contains both Tomcat and
> Jetty configuration information, which one should the deployer pick as
> a target especially if it is capable of targeting both. Further, the
> output of deployment here cannot be determined using just the
> information in the plan - it also depends on which web-container
> builder gets loaded by the deployer. This means you can get different
> and incompatible output bundles with the same configId.
This will be true if we allow a "generic plan" in any form. The only
way to prevent it is to only allow jetty or tomcat namespaces, not the
"generic" namespace.
I would be fine with that solution: I prefer that the plan namespace
unambiguously identify what builder will be used. However, I do not
feel too strongly about it today, and I believe Aaron and Jeff strongly
want "universal" plans.
>
> Rather than adding in extension elements, I think we should consider
> subclassing the generic schema for each container adding in as first
> class elements the items for that schema. We would then get something
> like:
>
> <web-app xmlns="http://geronimo.apache.org/xml/ns/web"
> configId="MyWebApp">
>
> <some-generic-setting ... />
> </web-app>
>
> <web-app xmlns="http://geronimo.apache.org/xml/ns/web/jetty"
> xmlns:web="http://geronimo.apache.org/xml/ns/web"
> configId="MyWebAppOnJetty">
>
> <web:some-generic-setting ... />
> <jetty:some-jetty-setting ... />
> </web-app>
>
> <web-app xmlns="http://geronimo.apache.org/xml/ns/web/tomcat"
> xmlns:web="http://geronimo.apache.org/xml/ns/web"
> configId="MyWebAppOnTomcat">
>
> <web:some-generic-setting ... />
> <tomcat:some-tomcat-setting ... />
> </web-app>
I don't see how to write schemas that these samples are valid for. I
think there might be a way to use substitution groups to do something
like what you are suggesting, but I have never used them and don't know
much about how they work. Simple schema extension wont result in a
usable schema IMO because the extension elements would have to go at
the end, after the gbean definitions: this is not acceptable to me.
In any case, if we go toward this kind of solution, I believe we have
to prohibit generic web plans to avoid the possibility of same input >>
different output based on deployer configuration.
Again, I am (slightly) in favor of namespace >> builder and no generic
web schema, but I am willing to accept the "any" configuration element
solution I''m about to commit. If we can agree on a namespace >>
builder solution I'm happy to fix the schemas and builders to work that
way, with as much schema inheritance as we can figure out how to
include. I'm not willing to accept the existing code with untyped
extensions.
thanks
david jencks
>
> The first would result in a configuration that could run on any web
> container, the last two would produce configurations that would run on
> a specific web container. Applications would typically use the first
> form unless they needed container-specific functionality (which would
> also mean that they needed that specific container at runtime).
>
> I included the namespace qualifiers for clarity. I believe that
> suitable use of schema imports would mean that they could be removed
> simplifying the XML form used by users. It may be harder for us to
> implement, but I think ease-of-use is more important here than
> ease-of-implementation.
>
> --
> Jeremy
>
Re: Web container-specific configuration
Posted by Dain Sundstrom <da...@iq80.com>.
+1 These are my sentiments as well.
-dain
On Aug 22, 2005, at 7:40 PM, Aaron Mulder wrote:
> I really disagree with having separate namespaces for the entire
> web deployment plan for Tomcat and Jetty. It makes Geronimo+Tomcat
> and
> Geronimo+Jetty totally different products. If I'm going to release a
> typical application for Geronimo, you're saying that every single
> bit of
> will be identical except for some stupid plumbing in the web
> plans? So
> you must release a Geronimo+Tomcat version of the application and a
> Geronimo+Jetty version of the application? Say it ain't so!
>
> I'll grant that it's possible to construct an application that
> works properly in only one container or the other. But I really
> object to
> crafting our whole configuration strategy around that case, which I
> expect
> to be very rare. I think it's going to be much more common that a
> plan is
> totally portable, or totally portable with a couple of container-
> specific
> tweaks for both containers that don't cause the app to fail if not
> deployed in its preferred container. I'd rather make that the
> baseline,
> and allow a generic plan and a generic plan with extensions for 0-N
> web
> containers.
>
> Aaron
>
> On Mon, 22 Aug 2005, David Jencks wrote:
>
>> After talking this issue over with Jeremy a bit and thinking about it
>> some more I don't think that the generic multi-container schema is a
>> good idea. I think the deployment system should be based on
>>
>> namespace determines builder
>>
>> and that we should not do anything that will make this difficult
>> in the
>> future.
>>
>> If the packaging plugin was working, we could, for each app (such as
>> the console) that needs to run on both containers, generate a
>> configuration for each container. Then you could run either one,
>> without rebuilding geronimo or the application config.
>>
>> I'm going to work on a proposal for schemas that would help keep the
>> configs for different containers as similar as possible.
>>
>> Meanwhile I've committed the "any" solution as I think it is
>> considerably better than what we have now. One problem with this is
>> that most tomcat configurations will not in fact be portable: if they
>> contain tomcat realm or tomcat valve gbeans, the config just plain
>> won't deploy under jetty. It might not be so easy, but I'm sure
>> there
>> are equivalent ways to get in trouble using jetty.
>>
>> Until we actually have the packaging plugin working, I suggest we
>> have
>> the tomcat and jetty builders munge a generic namespace to their
>> specific namespace, so that completely generic plans will still
>> deploy
>> on both.
>>
>> thanks
>> david jencks
>>
>> On Aug 22, 2005, at 5:51 PM, Jeff Genender wrote:
>>
>>
>>>> -----Original Message-----
>>>> The first would result in a configuration that could run on
>>>> any web container, the last two would produce configurations
>>>> that would run on a specific web container. Applications
>>>> would typically use the first form unless they needed
>>>> container-specific functionality (which would also mean that
>>>> they needed that specific container at runtime).
>>>>
>>>> I included the namespace qualifiers for clarity. I believe
>>>> that suitable use of schema imports would mean that they
>>>> could be removed simplifying the XML form used by users. It
>>>> may be harder for us to implement, but I think ease-of-use is
>>>> more important here than ease-of-implementation.
>>>>
>>>> --
>>>> Jeremy
>>>>
>>>>
>>>
>>> Everything you proposed is fine with me except for forcing the
>>> namespace for
>>> one container. I think we should have a universal web plan that
>>> will
>>> be
>>> accepted under both containers. So I would ask that we allow the
>>> generic
>>> file to be allowed to include both a jetty and tomcat name space.
>>> This will
>>> make our applications, like the console and debugtool to have 1
>>> geronimo-web.xml per app. IMHO this is a much simpler way to manage
>>> the
>>> apps that must run under both containers. I believe this is how DJ
>>> implemented it.
>>>
>>> Jeff
>>>
>>>
>>>
>>
>>
>
Re: Web container-specific configuration
Posted by Jeff Genender <jg...@savoirtech.com>.
Jeremy Boynes wrote:
> Dain Sundstrom wrote:
>
>> I would assert that most web apps are simple and do not require
>> complex container specific configuration, so a common plan is the
>> more desirable choice. In the rare places where tomcat and jetty
>> differ, we allow a name space designated escape to the container
>> specific elements.
>>
>> Lets make the commons stuff (80%) simple and have an escape system
>> for the complex (20%) installations.
>>
>
> Most environments will use one container or the other, not mix and
> match. Therefore keeping everything in the one namespace used by that
> container using the concepts people are familiar with is even simpler.
What is the downside to allowing both namespaces in the geronimo-web.xml?
>
> --
> Jeremy
Re: Web container-specific configuration
Posted by Jeremy Boynes <jb...@apache.org>.
Dain Sundstrom wrote:
> I would assert that most web apps are simple and do not require complex
> container specific configuration, so a common plan is the more
> desirable choice. In the rare places where tomcat and jetty differ, we
> allow a name space designated escape to the container specific elements.
>
> Lets make the commons stuff (80%) simple and have an escape system for
> the complex (20%) installations.
>
Most environments will use one container or the other, not mix and
match. Therefore keeping everything in the one namespace used by that
container using the concepts people are familiar with is even simpler.
--
Jeremy
Re: Web container-specific configuration
Posted by Dain Sundstrom <da...@iq80.com>.
I would assert that most web apps are simple and do not require
complex container specific configuration, so a common plan is the
more desirable choice. In the rare places where tomcat and jetty
differ, we allow a name space designated escape to the container
specific elements.
Lets make the commons stuff (80%) simple and have an escape system
for the complex (20%) installations.
-dain
On Aug 22, 2005, at 9:23 PM, Jeremy Boynes wrote:
> Aaron Mulder wrote:
>
>> I really disagree with having separate namespaces for the entire
>> web deployment plan for Tomcat and Jetty. It makes Geronimo
>> +Tomcat and
>> Geronimo+Jetty totally different products. If I'm going to release a
>> typical application for Geronimo, you're saying that every single
>> bit of
>> will be identical except for some stupid plumbing in the web
>> plans? So
>> you must release a Geronimo+Tomcat version of the application and a
>> Geronimo+Jetty version of the application? Say it ain't so!
>> I'll grant that it's possible to construct an application that
>> works properly in only one container or the other. But I really
>> object to crafting our whole configuration strategy around that
>> case, which I expect to be very rare. I think it's going to be
>> much more common that a plan is totally portable, or totally
>> portable with a couple of container-specific tweaks for both
>> containers that don't cause the app to fail if not deployed in its
>> preferred container. I'd rather make that the baseline, and allow
>> a generic plan and a generic plan with extensions for 0-N web
>> containers.
>>
>
> I would assert that most applications will be targeted at one
> environment or another. Most enterprise users will pick one
> platform and develop for that, most ISVs will pick one platform and
> distribute for that. In either case the overhead of testing all
> possible combinations will prove too expensive.
>
> Let's face reality: Geronimo+Tomcat and Geronimo+Jetty *are*
> different products - they even require separate certification.
> Anyone distributing an application is either going to ship the one
> they work with, or ship pre-tested deployment plans for both (just
> like they ship plans for JBoss, WebLogic or WebSphere).
>
> The choice of web container is actually non-representative of the
> general case as there is relatively little web-container specific
> configuration. When you look at EJB configuration etc. there is
> much more container specific information needed - are we going to
> define one plan for all EJB containers? Say it ain't so!
>
> This experiment with common web container configuration has shown
> that implementations *are* different, even down to basic concepts
> like what a "host" is. And that's just with two sample points, what
> about others?
>
> --
> Jeremy
>
Re: Web container-specific configuration
Posted by Jeremy Boynes <jb...@apache.org>.
Aaron Mulder wrote:
> I really disagree with having separate namespaces for the entire
> web deployment plan for Tomcat and Jetty. It makes Geronimo+Tomcat and
> Geronimo+Jetty totally different products. If I'm going to release a
> typical application for Geronimo, you're saying that every single bit of
> will be identical except for some stupid plumbing in the web plans? So
> you must release a Geronimo+Tomcat version of the application and a
> Geronimo+Jetty version of the application? Say it ain't so!
>
> I'll grant that it's possible to construct an application that
> works properly in only one container or the other. But I really object to
> crafting our whole configuration strategy around that case, which I expect
> to be very rare. I think it's going to be much more common that a plan is
> totally portable, or totally portable with a couple of container-specific
> tweaks for both containers that don't cause the app to fail if not
> deployed in its preferred container. I'd rather make that the baseline,
> and allow a generic plan and a generic plan with extensions for 0-N web
> containers.
>
I would assert that most applications will be targeted at one
environment or another. Most enterprise users will pick one platform and
develop for that, most ISVs will pick one platform and distribute for
that. In either case the overhead of testing all possible combinations
will prove too expensive.
Let's face reality: Geronimo+Tomcat and Geronimo+Jetty *are* different
products - they even require separate certification. Anyone distributing
an application is either going to ship the one they work with, or ship
pre-tested deployment plans for both (just like they ship plans for
JBoss, WebLogic or WebSphere).
The choice of web container is actually non-representative of the
general case as there is relatively little web-container specific
configuration. When you look at EJB configuration etc. there is much
more container specific information needed - are we going to define one
plan for all EJB containers? Say it ain't so!
This experiment with common web container configuration has shown that
implementations *are* different, even down to basic concepts like what a
"host" is. And that's just with two sample points, what about others?
--
Jeremy
Re: Web container-specific configuration
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I really disagree with having separate namespaces for the entire
web deployment plan for Tomcat and Jetty. It makes Geronimo+Tomcat and
Geronimo+Jetty totally different products. If I'm going to release a
typical application for Geronimo, you're saying that every single bit of
will be identical except for some stupid plumbing in the web plans? So
you must release a Geronimo+Tomcat version of the application and a
Geronimo+Jetty version of the application? Say it ain't so!
I'll grant that it's possible to construct an application that
works properly in only one container or the other. But I really object to
crafting our whole configuration strategy around that case, which I expect
to be very rare. I think it's going to be much more common that a plan is
totally portable, or totally portable with a couple of container-specific
tweaks for both containers that don't cause the app to fail if not
deployed in its preferred container. I'd rather make that the baseline,
and allow a generic plan and a generic plan with extensions for 0-N web
containers.
Aaron
On Mon, 22 Aug 2005, David Jencks wrote:
> After talking this issue over with Jeremy a bit and thinking about it
> some more I don't think that the generic multi-container schema is a
> good idea. I think the deployment system should be based on
>
> namespace determines builder
>
> and that we should not do anything that will make this difficult in the
> future.
>
> If the packaging plugin was working, we could, for each app (such as
> the console) that needs to run on both containers, generate a
> configuration for each container. Then you could run either one,
> without rebuilding geronimo or the application config.
>
> I'm going to work on a proposal for schemas that would help keep the
> configs for different containers as similar as possible.
>
> Meanwhile I've committed the "any" solution as I think it is
> considerably better than what we have now. One problem with this is
> that most tomcat configurations will not in fact be portable: if they
> contain tomcat realm or tomcat valve gbeans, the config just plain
> won't deploy under jetty. It might not be so easy, but I'm sure there
> are equivalent ways to get in trouble using jetty.
>
> Until we actually have the packaging plugin working, I suggest we have
> the tomcat and jetty builders munge a generic namespace to their
> specific namespace, so that completely generic plans will still deploy
> on both.
>
> thanks
> david jencks
>
> On Aug 22, 2005, at 5:51 PM, Jeff Genender wrote:
>
> >> -----Original Message-----
> >> The first would result in a configuration that could run on
> >> any web container, the last two would produce configurations
> >> that would run on a specific web container. Applications
> >> would typically use the first form unless they needed
> >> container-specific functionality (which would also mean that
> >> they needed that specific container at runtime).
> >>
> >> I included the namespace qualifiers for clarity. I believe
> >> that suitable use of schema imports would mean that they
> >> could be removed simplifying the XML form used by users. It
> >> may be harder for us to implement, but I think ease-of-use is
> >> more important here than ease-of-implementation.
> >>
> >> --
> >> Jeremy
> >>
> >
> > Everything you proposed is fine with me except for forcing the
> > namespace for
> > one container. I think we should have a universal web plan that will
> > be
> > accepted under both containers. So I would ask that we allow the
> > generic
> > file to be allowed to include both a jetty and tomcat name space.
> > This will
> > make our applications, like the console and debugtool to have 1
> > geronimo-web.xml per app. IMHO this is a much simpler way to manage
> > the
> > apps that must run under both containers. I believe this is how DJ
> > implemented it.
> >
> > Jeff
> >
> >
>
>
Re: Web container-specific configuration
Posted by David Jencks <da...@yahoo.com>.
After talking this issue over with Jeremy a bit and thinking about it
some more I don't think that the generic multi-container schema is a
good idea. I think the deployment system should be based on
namespace determines builder
and that we should not do anything that will make this difficult in the
future.
If the packaging plugin was working, we could, for each app (such as
the console) that needs to run on both containers, generate a
configuration for each container. Then you could run either one,
without rebuilding geronimo or the application config.
I'm going to work on a proposal for schemas that would help keep the
configs for different containers as similar as possible.
Meanwhile I've committed the "any" solution as I think it is
considerably better than what we have now. One problem with this is
that most tomcat configurations will not in fact be portable: if they
contain tomcat realm or tomcat valve gbeans, the config just plain
won't deploy under jetty. It might not be so easy, but I'm sure there
are equivalent ways to get in trouble using jetty.
Until we actually have the packaging plugin working, I suggest we have
the tomcat and jetty builders munge a generic namespace to their
specific namespace, so that completely generic plans will still deploy
on both.
thanks
david jencks
On Aug 22, 2005, at 5:51 PM, Jeff Genender wrote:
>> -----Original Message-----
>> The first would result in a configuration that could run on
>> any web container, the last two would produce configurations
>> that would run on a specific web container. Applications
>> would typically use the first form unless they needed
>> container-specific functionality (which would also mean that
>> they needed that specific container at runtime).
>>
>> I included the namespace qualifiers for clarity. I believe
>> that suitable use of schema imports would mean that they
>> could be removed simplifying the XML form used by users. It
>> may be harder for us to implement, but I think ease-of-use is
>> more important here than ease-of-implementation.
>>
>> --
>> Jeremy
>>
>
> Everything you proposed is fine with me except for forcing the
> namespace for
> one container. I think we should have a universal web plan that will
> be
> accepted under both containers. So I would ask that we allow the
> generic
> file to be allowed to include both a jetty and tomcat name space.
> This will
> make our applications, like the console and debugtool to have 1
> geronimo-web.xml per app. IMHO this is a much simpler way to manage
> the
> apps that must run under both containers. I believe this is how DJ
> implemented it.
>
> Jeff
>
>
RE: Web container-specific configuration
Posted by Jeff Genender <jg...@savoirtech.com>.
> -----Original Message-----
> The first would result in a configuration that could run on
> any web container, the last two would produce configurations
> that would run on a specific web container. Applications
> would typically use the first form unless they needed
> container-specific functionality (which would also mean that
> they needed that specific container at runtime).
>
> I included the namespace qualifiers for clarity. I believe
> that suitable use of schema imports would mean that they
> could be removed simplifying the XML form used by users. It
> may be harder for us to implement, but I think ease-of-use is
> more important here than ease-of-implementation.
>
> --
> Jeremy
>
Everything you proposed is fine with me except for forcing the namespace for
one container. I think we should have a universal web plan that will be
accepted under both containers. So I would ask that we allow the generic
file to be allowed to include both a jetty and tomcat name space. This will
make our applications, like the console and debugtool to have 1
geronimo-web.xml per app. IMHO this is a much simpler way to manage the
apps that must run under both containers. I believe this is how DJ
implemented it.
Jeff
Re: Web container-specific configuration
Posted by Jeremy Boynes <jb...@apache.org>.
David Jencks wrote:
> After a lot of discussion about the virtual-host configuration, Aaron,
> Jeff and I think that the best way to proceed is to have xml schemas for
> container specific configuration and include the virtual host in the
> container specific config. This will replace the current name/property
> container specific config.
>
> Why put the virtual host into container specific config? well, the
> meaning of specifying "virtual-host" in jetty and tomcat are really
> different. In tomcat this is a reference to a preconfigured list of
> host + multiple aliases, and if will fail if the host is not already
> configured. In jetty, this simply adds the VH string to some routing
> code inside jetty. If we reused the same syntax for both containers,
> you would get surprising results whenever you switched containers unless
> you were very aware of the different meanings.
>
> How will the proposed container specific config work? I'll add an any
> element in the geronimo-web schema, and each builder will look for its
> own namespace and interpret it as appropriate. This will allow one plan
> to be deployed on multiple web containers.
>
>
> comments?
>
I'd ask that we settle on something once and for all. This was changed
once from container-specific to generic (breaking every existing plan),
changed again to add in container-specific options, and now we're
changing yet again having cut a release somewhere in the middle.
Before rushing to implementation, can we please put some more
consideration and discussion into up-front design.
On the technical front, I remain uncomfortable with a single generic
namespace as there is no way for the deployment system to tell what the
target container will be. If the plan contains both Tomcat and Jetty
configuration information, which one should the deployer pick as a
target especially if it is capable of targeting both. Further, the
output of deployment here cannot be determined using just the
information in the plan - it also depends on which web-container builder
gets loaded by the deployer. This means you can get different and
incompatible output bundles with the same configId.
Rather than adding in extension elements, I think we should consider
subclassing the generic schema for each container adding in as first
class elements the items for that schema. We would then get something like:
<web-app xmlns="http://geronimo.apache.org/xml/ns/web"
configId="MyWebApp">
<some-generic-setting ... />
</web-app>
<web-app xmlns="http://geronimo.apache.org/xml/ns/web/jetty"
xmlns:web="http://geronimo.apache.org/xml/ns/web"
configId="MyWebAppOnJetty">
<web:some-generic-setting ... />
<jetty:some-jetty-setting ... />
</web-app>
<web-app xmlns="http://geronimo.apache.org/xml/ns/web/tomcat"
xmlns:web="http://geronimo.apache.org/xml/ns/web"
configId="MyWebAppOnTomcat">
<web:some-generic-setting ... />
<tomcat:some-tomcat-setting ... />
</web-app>
The first would result in a configuration that could run on any web
container, the last two would produce configurations that would run on a
specific web container. Applications would typically use the first form
unless they needed container-specific functionality (which would also
mean that they needed that specific container at runtime).
I included the namespace qualifiers for clarity. I believe that suitable
use of schema imports would mean that they could be removed simplifying
the XML form used by users. It may be harder for us to implement, but I
think ease-of-use is more important here than ease-of-implementation.
--
Jeremy