> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: 4. lipanj 2002 20:34 > To: Mladen Turk > Cc: List Tomcat-Dev > Subject: RE: [PATCH] Apache2 mod_jk2 > > > 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 > interfaces/concepts.
Fine with me. > > > 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 ). > Again fine with me. > > > ...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). I can extend the JkUriSet, but I need the the table of handlers, input filters, output filter and protocols that I'll go through, for each particular hook. The SetJavaHandler is only example for handler modules. SetJavaInputFilter and SetJavaOutputFilter are other two. I'm afraid that JkUriSet doesn't allow that. Of course it can be extended to keep the config directive count low, like 'JkUriSet handler someHandler', and will be confusing. > 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. > That's my goal too. The Java side will have all the interface, and C side will just find the paticular hook, and implement the missing interface. > > > 1. The directive JavaHandler will load the handlers in the handlers > > table > > jk2.properties is doing that ( but on java side ), > workers.properties can add the C side for the bridge. > Again I need four special data structures that consists of synced apr_table, and apr_hash_table, bassicaly the extended jk_map_aprtable. I'd like to minimize the various configuration files. Modules will be the part of Apache server and IMO their configuration should be inside the server configuration file. > > 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. Fine with me. > > 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 > optimized. > > > > 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. > Agree! Will check. > 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 ). > > > Costin Thanks. MT. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
