Well JK using APR will be a good solution for every webservers but Apache 1.3.x.
Apache 2.x came with APR, IIS, Domino and others should have no problems to use an external APR library (.so, .dll).
So the remaining question will be shoud we drop Apache 1.3.x support in future JK 1.2.x or should we start a 'new' APR JK 1.2.x based implementation ?
Why use APR in mod_jk ?
Support for Apache1.3 is IMO more important than support for IIS. And so far, mod_jk seems to work without any apr - and it is in maintainance mode, so no major changes should be made.
Costin
On Fri, 08 Oct 2004 16:53:40 -0400, Kurt Miller <[EMAIL PROTECTED]> wrote:
From: "Mladen Turk" <[EMAIL PROTECTED]>
Remy Maucherat wrote:
Over all, I don't, personally, think that it's worth trying to build on the existing Jk code base. However, if you have an itch....
Well, we deceased JK2, for Apache2.1 we have proxy_ajp. Until Apache2.1 becomes the only server around the net, I'll stick with JK for all those not running my preferred web server :).
Right. However, I think JK 1.2.x needs some level of stability. So APR, large architectural changes, etc seem bad ideas. Of your list, I think documentation (yah !) and the Unix sockets backport would be good (if not too complex), but that's about it. Modifications to the Java side is something independent.
I think it would rise the stability, but introduce new problems like building APR, etc.. so you are probably right. We'll see.
I'm not very happy with the integrated APR build in JK2 for Apache 1.3. I did much of the work there and if I had to do it again, I'd prefer APR to be a build/runtime depend, built separately by the user first and loaded with LoadFile directive.
With respect to JK, I'd rather not see it get APR'ized. Mostly so that Apache 1.3 support is kept simple and straightforward.
For the long term, if you would want better support for the other servers, you can start a 100% APR replacement for JK 1.2 (I think it was a bit like your mod_ajp) if you want to.
I'm surely do. The IIS6 support is something to chase :).
MT.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
