tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Todd <james.t...@eng.sun.com>
Subject Re: config diag, etc
Date Wed, 04 Aug 1999 01:49:50 GMT

comments included,

- james

rubys@us.ibm.com 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.

hmmm ... is it not so that any application (tool, client) could request
config information vi a known uri? with this model, the client need not
be java based at all. it simply must be able get/post http requests,
read/
write the appropriate data and mantain a session id.

now, if we're discussing the "tightly coupled" configuration scenario
(the dotted lines around tomcat) then 1) this is pretty much what tomcat
does today and 2) it is 100% java.

i did not finish this diagram. i have not shown all possible paths
(there are a bit many options, which is good, as it stands). i did
not mean to imply that apache, for example, needs to embedd the config
lib (ie the "tightly coupled" scenario). i should add to the diagram
that apache, for example, could interact with the config service via
http/s connecting with the servlet handler of the config service.

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

i don't see the complication.

i think the "client-to-data" mapping should best be relegated to the
client element making the request (ie tool, tomcat, apache).

that said, there is the possibilty of providing some "pass through"
data (eg xml) from repositor (far right of diagram) to the requestor
(far left) but up to this point in time i have laid on the table well
defined config data based on tomcat's definition to date ... which is
probably a prettly small subset of apache config, for example.

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

we haven't really discussed message formats to date. why is it not
possible to pass xml text over http to/from the config service by
the tool clients? in fact, as we look at this further, i believe the
two "service" tiers will meld into one ... this is the point troy and
i are pondering at this moment.

> 
> I find the thoughts recently posted by Stefano Mazzocchi considerably more
> appealing.  I'll paraphrase them thus:
> 
> 1) XML Format = good.

yes

> 2) DOM API = good

yep

> 3) Apache integration = good

in addition to other clients ... eg tomcat. there are a couple of other
pure java http servers at the table here as well. i think alot can be
discovered by factoring in a smallish application to better see the
details apart from the implemenation ... my perspective.

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

your words not mine. i have never thought of apache config as out of
scope
here.

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

agreed on the breakdown. i personally have seen nothing to date
stating otherwise.

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

ok ... but i'm not sure how anything that has been presented from
my perspetive is in contrast to what you or stefano has stated.
help me out here. i actually think perspectives are quite aligned
compared to the early ramblings on this list. i really don't see
how my posting is contrary. can you list the details which concern
you with which i can discuss. i believe i've done a fair job at
addressing your concerns up until this point.

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

assuming your talking about the "tightly coupled" (put another way,
the "not a remote service") scenario. if so, then i'd agree. that
said, i'm really not a big proponent of the "tightly coupled" scenario
to begin with but i do believe it should be accounted for, hence the
reason i stubbed it in the diag without describing it to the fullest.
my bad.

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

assuming we're talking about a "distributed config service" ...

not in all cases. if the config service servlet where to serve up
xml content (or some other format) i'm not sure what is to be gained
by introducing an ejb layer in tomcat when all it need to do is 1)
obtain the config data and 2) set the appropriate internal hooks.
there's really not much more going on at this layer then that.

> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Mime
View raw message