On May 20, 2009, at 7:44 AM, Ivan wrote:
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.
Not exactly.
Right now we supply one preconfigured tomcat server in the tomcat
plugin. You can deploy more if you want, and your app can choose
which one to use with the (IIRC) web-container element in its plan.
You can also use artifact-aliases to get one you deploy to replace the
standard one.
I'm suggesting writing a builder, maybe tomcat-server-builder, for
server.xml files that produces plugins that are similar to the tomcat
plugin. What happens to these plugins is a separate question. I'd
assume most people would want to replace the supplied tomcat plugin
with the one built out of their server.xml file but this is not an
essential part of what I'm suggesting.
thanks
david jencks
Right ?
Ivan
2009/5/20 Lin Sun <[email protected]>
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
<[email protected]> 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
