I'd like to throw more gasoline on this fire by extending my proposal
below:
1. Use the gbean.enabled attribute extensively and include both the
jetty and tomcat servers in the main config, with possibly one of them
disabled: extend the config db so it can save the enabled/disabled
state. Then you can turn the one you want on or off.
2. Write a delegating web deployer that has a default deployer, used
for "no plan" and "generic plan": others it points to the correct
deployer based on the namespace.
Then we will need only one set of plans, and one assembly.
thanks
david jencks
<snip>
So, I realize there is a bit of weakness in my idea, namely a lot of
web apps don't need a plan: so in my rosy future, there would need to
be a "default web container" that these would get pushed to. So, how
about this idea:
a "fake" common schema that includes the common elements and a single
[virtual-]host element
a jetty schema that is the same except allowing multiple virtual-host
elements
a tomcat schema that is the same but includes the additional tomcat
specific elements.
The tomcat and jetty builders can both change the common namespace to
their own namespace and deploy as if it is their own.
This takes care of 100% of the cases you mentioned :-) However, it
doesn't take care of the <cross-context/> element which can be put in
the tomcat config without making it undeployable on jetty. I'll
actually weaken my case a bit by pointing out that the tomcat specific
gbeans relating to the tomcat-realm and valve-chain should probably
come from tomcat specific xml in the tomcat schema rather than plain
gbean definitions.
Could you live with this proposal?
thanks
david jencks
