tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: [PATCH] Apache2 mod_jk2
Date Tue, 04 Jun 2002 18:33:55 GMT
On Tue, 4 Jun 2002, Mladen Turk wrote:

> There will be four classes dealing with particular Apache hook 
> 1. Handler
> 2. Input Filter
> 3. Output Filter
> 4. Protocol

For Handler - you should use JkHandler. We can add some more methods
if you need, but it would be better to minimize the number of 

> JavaHandler someHandler "/home/somehandler.jar"
> JavaHandler anotherHandler "/home/anotherhandler.jar"

I assume you want the jar files loaded in the VM ? It's much easier
to just put them in the lib/common ( or common/lib ). It is also
possible to have some defined in web applications ( WEB-INF/lib ),
but it's much easier to deal with this in the java side.
( and keep the C code simpler ).

> ...etc
> <Location /some-handler>
>     SetJavaHandler someHandler
> </Location>

That's already done and works fine. It's "JkUriSet name value", 
you can do:
  JkUriSet group lb
  JkUriSet debug 1
  JkUriSet worker status

We can add a 'handler' property to reflect the java-side handler that
will be executed ( or one for the handler type and one for the instance).

Again, the goal is to keep the C-Java interface to a minimum that can
be optimized, and do more work on the java side.

> 1. The directive JavaHandler will load the handlers in the handlers
> table is doing that ( but on java side ), can
add the C side for the bridge.

> 2. The per-directory SetJavaHandler will associate the location with
> particular handler

I think the current system will work, if you need extensions its fine
but I wouldn't go with a different path of execution for that ( if you 
think there are serious problems with the current mapper system - we
can either fix or replace, but I really want to reuse the same code )

> 3. On first invocation will create the JVM and call the Initialize
> method from someHandler class

Again, that's part of the channeljni - and should be the same code as for
normal requests.

> 4. AjkHandler will load the callbacks from mod_jk2.

Are you talking about Java->C ? The JniHandler is able to call any jk
component ( that's what we use for shm and mutex etc ), and is quite 

> Each module will be ran inside its own JVM for now, this can be wrapped
> with the JVM pool, and using the inactive one.

It's a bit inefficient, it's much better to have a single VM and maybe
use different classloaders. Keep the complexity in java, it's much easier.

> All that is for the pure Java modules without Tomcat at all.
> It can be used inside the Tomcat itself, but only using jni or writing
> new protocol stack (something like RPC), but I'm not sure what would be
> the purpose of that. I'll be glad to hear some thoughts on that.

You don't need full tomcat - but the java side of Jk2. The 'RPC-like'
mechansim is already in place to allow request forwarding and callbacks
and general Java-C communication. 

It is not very sophisticated ( i.e. simple enough to be optimized ), and
may be extended ( I haven't implmented the signals yet, and few other
things that may be needed in future versions of jk2 ).


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message