geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Web container-specific configuration
Date Tue, 23 Aug 2005 02:40:13 GMT
	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 


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
> >
> >

View raw message