tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <cmanola...@yahoo.com>
Subject RE: new config plan
Date Mon, 02 Jul 2001 17:32:33 GMT
On Mon, 2 Jul 2001, GOMEZ Henri wrote:

> >The plan is:
> >- start by fixing jk_uri_worker_map to support the virtual host
> >( it's one of the biggest missing points ).
>
> virtual host will be present in ajp14 :!
> Even more It will be the KEY :

Well, jk_uri_worker_map is common for all, so if it's implemented in one
it'll be implemented in all :-)

The only problem is that regardless of the protocol or configuration
mechanism, we need to:
- collect all relevant information from web.xml, server.xml and pass it to
mod_jk/web server.
- as long as mod_jk ( using either autoconf or generated
uriworker.properties or generated native config ) can't handle all
settings in web.xml, we should default to sending all requests for a
context to tomcat. A small improvement will happen in ajp14, where we'll
be able to tell mod_jk to send chunks ( so static files will be served by
apache, but with an eventual round trip to tomcat )

I also want to fix few small problems in mod_jk, to allow manual
configuration ( where you specify the handler for *.jsp or something else
using SetHandler ) to completely override mod_jk ( i.e. avoid the double
mapping in apache and jk_uri_worker_map ).

> >- extend the jk_map to support a bit more advanced properties, where
> >instead of name=value we'll have "tuples" ( host:uri=worker ).
>
> Easy using a separator like : or others not found in std URI....

Something like that - easy to parse ( I'm looking at minimal extensions to
the current C configuration code in mod_jk ).

BTW, there is value in having a "uniform" configuration for all servers,
i.e. stop passing config options in server.xml format ( and obj.conf,
registry, ini ), but use the same mod_jk.properties and
urimaps.properties.

( the value is simpler documentations, simpler code ).

Another value ( for me ) is that it'll allow my other project ( very small
footprint tomcat, without xml parsing and any other big thing - i.e. a
j2me-class runtime ). The "simpler to parse but complete" urimaps can also
be used by standalone embeded tomcat.


> >- 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.
>
> You speak about the java side ?

I wish :-)

Well, I'll start with the java side and the uriworkermap, which is already
known by mod_jk.


> May I ask you J-T-C developpers to wait one (may be two weeks)
> and take a look at autoconf I'm finishing rigth now ?

Well, I have 2 full days to work on that ( today and tommorow ), I have a
small vacation ( but only 2 days of it will be for tomcat ).

I'm not working on the autoconf right now, collecting all mappings in java
is the first step.

> I must mention I forget about welcome and didn't know how to handle
> security rigth now. But it wasn't in ajp14 stricto-senso....

Form login is the another hard one. Again, as long as we can't handle all
web.xml, I think we must default to forward-only ( and manual mode if
someone wants static files served by apache ).

Costin


Mime
View raw message