On May 19, 2009, at 8:17 PM, Lin Sun wrote:
I am not a tomcat expert either... :-) I think we could also try the
following approach:
1. figure out how to read tomcat server.xml like you described.
Tomcat is using
2. at the G server startup, transform data in tomcat server.xml into G
config.xml, if there is change to server.xml since last time server
started. I think coming up for the mapping could be hard as
configuring some features like valve or cluster requires
documentation, time and experience. Also, there could be some
functions/configurations in server.xml that we don't support in G yet.
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.
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.
thanks
david jencks
Lin
On Tue, May 19, 2009 at 6:09 PM, David Jencks
<[email protected]> wrote:
I'm not enough of a tomcat expert to know exactly what information a
server.xml contains so I'm not quite sure how much the following
makes
sense.
I think I would approach this by building a namespace aware builder
that can
interpret documents following the server.xml schema and construct
the
entire tomcat server from it. In other words, instead of starting
with our
current tomcat6 plugin, the builder would construct a replacement
for it
from the server.xml. If server.xml contains info on apps that are
deployed
in the tomcat instance, this could perhaps hook into or extend the
current
TomcatModuleBuilder to also set up plugins for each web app involved.
The first part here might not be too hard. IMO if we treat the
server.xml
as a geronimo plan that would be acceptable. I'd recommend trying
jaxb
rather than using xmlbeans. I don't know how practical this would
turn out
to be but it's worth starting with.
I personally think this is too large an addition to plan to get
into 2.2.
However if a motivated person shows up with something working
before we
solve the other problems I think we could consider it. 2.2 is
already so
much later than we had planned I don't want to hold it up for any new
features after the other problems have been solved.
thanks
david jencks
Lin
On Mon, May 18, 2009 at 3:49 PM, Bill Stoddard <[email protected]
>
wrote:
I know G can't consume tomcat configs today, but is this a
feature that
could be developed for G 2.2?
Say I have an application successfully deployed and running under
Tomcat..
wouldn't it be nice if I were able to drop the tomcat server
config into
a
Geronimo-Tomcat assembly, start the server, deploy the app and
be up and
running in seconds. I'm talking about a seamless, zero effort/
zero
touch
migration from Tomcat to a Geronimo-Tomcat assembly. Is it
possible?
If
not, what simplifying assumptions could be made to 'mostly'
achieve a
zero-touch migration?
What are the primary challenges with consuming a tomcat config
unchanged
with a G-Tomcat assembly? Same Q's apply for Jetty... what's
'doable'
with-in reason?
Thanks,
Bill
