tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Poppe <>
Subject Re: config diag, etc
Date Wed, 04 Aug 1999 02:09:34 GMT
On Tue, Aug 03, 1999 at 08:49:09PM -0400, wrote:
> 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 think the drawings definately take a slant on Java as it implementation, but
what is missed by the drawings is the underlying API.  Given an API that provides
an interface to the configuration service, and also abstracts out the source of
the configuration data, its really up to the implementation.

The purpose of the drawings that James and I did was to diagram how a Java
implementation might work, as a 'framework' for the API.  "This component needs
to talk to this component, which in turn retrieves data from any number of sources,
without relying on any specific interface" is the intended meaning (for mine ;))

> 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

To me, XML is a format for the data, as you have stated.  The DOM API merely
specifies ONE manner of looking at the data.  Apache is just ONE client for the

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

I don't think anyone here is intent on pursuing anything but a good API and a
solid implementation.  So where do we begin?  Looking at data formats, (ie. how
the clients want data back) or looking at what services the client needs?

> 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).

Maybe even though the 'other' blob in the service column.  This would allow for
clients to be applications that use some other type of protocol/access method to
get to/control the configuration manager.

- Troy

View raw message