tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cmanola...@yahoo.com
Subject jk: new config plan
Date Sun, 01 Jul 2001 08:23:56 GMT
I think I found a good way to implement the previous proposal, it should
solve the short term problem and allow later development.

The plan is:
- start by fixing jk_uri_worker_map to support the virtual host 
( it's one of the biggest missing points ).

- extend the jk_map to support a bit more advanced properties, where
instead of name=value we'll have "tuples" ( host:uri=worker ).

- replace the 3 config generators with a single one, generating 
_all_ the mappings known to the server ( exactly the information that is
used in SimpleMapper ), using the easy-to-parse format.

- The workers.properties will be "pre-cooked", i.e. the goal is to
minimize the processing on the C side. The format I have in mind right now 
is a simple extension to the name=value, and I would go one more step
and add:
  exact:host:uri=worker:contextPath:servlet
  prefix:....
  
  security:host:uri=...
 
  welcome:host:context=index.jsp

Etc.

On the first stage, most information will be ignored. It's _extremely_
difficult to support all the web.xml configurations, for example I don't
think it's even possible to  support different welcome files based on 
context ( it is eventually possible in apache - but I couldn't find a way
in NES or IIS ). 

So we'll start with just redirecting all the requests ( and later, when
the jasper's extensions will be added, the static files will go 
back to beeing served by apache ). 

What I want is to have _all_ mapping info available, even if it'll
not be used right away. 

A next step would be to implement the mapping alghoritm used in
SimpleMapper and AccessInterceptor - in C, part of uri_worker_map. Then
static files will stay with apache from beginning ( but still we'll 
duplicate the native server mapping ). A third step would be to try again
to generate native rules - apache2 supports API access to configuration.

The "tuple" style for the config file will also help a lot in implementing
the Ajp14, but for now I think extending uri_worker_map and adding the
rest of the infrastructure is more important.

Regarding 'manual mode': in the handler we must check if worker is null,
and call uri_worker_map ( or use the "default" worker ). That would allow 
native server config that sets the handler. 

I'm not sure having more than a protocol in use is a common case ( even
for loadbalancing, the default will be the lb worker - so we can still use
the default ).

On another front, we should reduce the configs in the server, and use the 
worker.properties and urimap.properties for most configurations (
i.e. common for all servers ) ( debug, log file, etc )

Costin



Mime
View raw message