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....@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_jen...@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
