tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <gr...@mortbay.com>
Subject Re: request for review: server/config discussion
Date Mon, 19 Jul 1999 22:45:45 GMT
James Todd wrote:
>         attached is a first cut at collecting the various
>         thoughts surrounding a "pure java http server
>         configuration" project.

James,

A good start to formalizing these discussions, but a number 
of suggestions

The language/terminology of the document is firmly directed at
configuration of a 100% java HTTP server.   It may be
better to adjust the language to be a little more
deployment nuetral and in line with the project definitions
we have seen to date.   For example, it is probably worthwhile
to structure the "Data Consumer Model" section along the lines of  

Jakarta module configuration
  |
  + Jakarta Communciations connector configuration
  |  + Adaptor configuration
  |  |   + Apache
  |  |   + Netscape
  |  |   + ...
  |  + HTTP Server config
  |
  + Servlet Container configuration
  |  |
  |  + Servlet Configuration
  |  |   + JSP Servlet Configuration
  |  |   + CGI Servlet Configuration
  |  + ???
  |
  + New and wonderful module configuration 

Configuration of a HTTP server is only one aspect of configuring
"Jakarta"

Note that I think all configuration should be module based and
all jakarta modules should share a common set of params. As much
of jakarta will be dynamic and hopefully restartable, things like
module name, CLASSPATHs and class loaders for each module 
should be common. 

While I think you document does make the distinction between the
configuration model, it's flat file format and the service that
provides configuration - It think the distinctions need to be
made clearer:

 + As Craig has suggested, we need to talk about the services
   that provide configuration and their dynamic behaviour.
   I see a mechanism similar to a window redraw API. The service
   can tell us exactly what has changed in the config file (the region),
   and config clients have the option of just refreshing that part of 
   the config, or giving up and refreshing the whole module.

 + As somebody else pointed out - the call to go XML has not
   yet been made - so it is important to clearly separate
   the data model from potential file formats.  Again this
   will require work on the API so that it is decoupled from
   any XML package.

You doc does cover these points - but I think a lengthy configuration
architecture and philosophy statement is needed up front (including
the protocol and management architecture etc.).  I'm happy either 
to contribute to this if James continues as primary author - or 
write a first draft if my ramblings here a along the lines of
what others are thinking...

regards

-- 
Greg Wilkins<gregw@mortbay.com>          GB  Phone: +44-(0)171-4394045
Mort Bay Consulting Australia and UK.    Mbl Phone: +44-(0)7775534369
http://www.mortbay.com                   AU  Phone: +61-(0)299772395

Mime
View raw message