geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: Possible for G to directly consume a Tomcat server config w/o changes?
Date Wed, 20 May 2009 14:44:47 GMT
I guess that what David means is that writing a deployer for server.xml,
then in the builder class, construct those tomcat server gbeans, and add
those gbeans to the tomcat plugin section in the config.xml. So that we
could imitate a totally same tomcat environment for those tomcat-ready
applications.
Right ?
    Ivan

2009/5/20 Lin Sun <linsun.unc@gmail.com>

> One example that we did this is with the config-substitution property
> file where we allow users to specify configuration and the server
> reads the config-substitution property file during the startup of the
> server.   If we more or less freeze the configuration, wouldn't this
> (reading data from server.xml and build the tomcat plugin) have to be
> done at the build time when we build the geronimo plugin for tomcat
> using maven2?    I think the user would want to do this at runtime
> where the geronimo server is already prebuilt.
>
> On Wed, May 20, 2009 at 3:16 AM, David Jencks <david_jencks@yahoo.com>
> wrote:
>
> > I'm not sure about this idea.  It seems really contrary to how most of
> > geronimo works.... where we take some kind of plan and more or less
> freeze
> > the configuration while "pre-deploying" it into a pretty much immutable
> > plugin.  I'm not convinced that accepting a new kind of plan for a few
> > gbeans requires adding this "continual redeploy" functionality to
> geronimo.
> >
> >>
> >> 3. During G startup, G can just build the embedded tomcat server by
> >> reading data from config.xml, like what it is doing today.
> >
> > config.xml doesn't have to contain any info on the tomcat server except
> that
> > it ought to be started, i.e. listing the plugin.  The gbean
> configurations
> > are all serialized in the plugin.  I'd generally prefer it if we dropped
> the
> > ability to add gbeans to a plugin via config.xml.
>
> Again, this may be something that I don't understand well.  If we
> don't configure it in config.xml, how do we allow users to drop in
> their tomcat server.xml without rebuilding the tomcat plugin?
>
> >>
> >> AFAIK, server.xml doesn't contain any app info.   I agree that this is
> >> a very big change and requires a lot of testing to make sure things
> >> are not regressed.
> >
> > Adding this new namespace driven builder is entirely new functionality so
> > there is not really any chance of regressions unless we decide to deploy
> the
> > "standard" tomcat server this way, which is certainly not necessary to
> > adding the feature.  So, to me the only problems are actually writing the
> > deployer and making sure it at least sort of works.
>
> To me, anything that has been changed needs to be tested somehow :)
> Regarding writing the deployer, I assume you meant the ability for G
> to deploy tomcat ready web archives.   I think this can involve a
> large number of work, basically, we have to be able to generate
> geronimo-web.xml for the user's web archives, and deploy the web
> archive using the generated geronimo-web.xml file.
>
> Lin
>



-- 
Ivan

Mime
View raw message