tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: config diag, etc
Date Wed, 04 Aug 1999 00:49:09 GMT

If I read these diagrams correctly, both the administrative tool on the client
and even the presentation and service interfaces are completely unaware of the
data representation.  All requests are routed through one of two EJB interfaces.

In my mind, this:

1) pretty much rules out sharing of implementation with the base Apache team
which to date has found no need to launch a JVM, let alone host an EJB.

2) complicates the task of producing a single configuration tool which aspires
to configure the entire server, as some of the information collected from the
user will have to be handled the Apache way, and the remainder the TomCat way.

2) pretty much rules out the configuration tool taking advantage of any
knowledge that the internal format is XML.  There are a lot of technologies
which will provide considerable assistance if this were reversed.

I find the thoughts recently posted by Stefano Mazzocchi considerably more
appealing.  I'll paraphrase them thus:

1) XML Format = good.
2) DOM API = good
3) Apache integration = good

There seem to be those who are intent on pursuing a standalone TomCat, and view
Apache configuration as explicitly "out of scope".  I personally think this is
both unnecessary and unfortunate.  I believe that we can agree on a core set of
either data formats or interfaces that satisfy three different configurations:
(1) standalone Apache (no servlet), (2) standalone TomCat (no Apache), and full
(3) jakarta.apache (Apache web server + Jakarta servlet+JSP) implementations.

And I believe that this would fall pretty much along the lines spelled out by

The corrections required to the config diagrams posted would be pretty simple:
there would need to be some lines from the client admin tools and/or the
presentation JSPs directly to the configuration parser (xml).

Note: a standalone TomCat server would certainly need to have code that fills
the void left by the removal of Apache.  This could certainly include EJB
encapsulation of the configuration file formats.

View raw message