The original intention for mod_jk was to use APR whenever it's ready. Gal
wrote most of the "general" code trying to stay as close as possible to
APR semantics.
Since mod_jk is using just a few APR-like functions, the transition
woulnd't be difficult - but it's important to do it at the right time.
And IMHO that should come as a decision from tomcat-dev - I would feel
very bad if Henri or Dan would decide to switch to APR without a serious
discussion on tomcat-dev.
And at this moment I would be strongly -1: APR is still beta, while tomcat
is used in production, the code we use works and has been ported on
most platforms we care, the extra overhead will hurt users, and I don't
know any real-world use of APR as a portable runtime with NES or IIS or
AOLServer - it should work, but I need to see at least one proof before
we start depending on that.
Of course, I can't -1 something in mod_webapp - since nobody asked or
proposed or discussed any of the mod_webapp developments ( or even
requirements, or anything else for that matter - except announcements
about the progress ).
Costin
On Thu, 22 Mar 2001, jean-frederic clere wrote:
> GOMEZ Henri wrote:
> > >No, that is not exactly the goal of APR, it is USED by APACHE2.0 but
> > >should/could be standalone. But it means probabably 2
> > >portables run time for the
> > >non-Apache servers.
> > >
> > >I prefer to use apr_socket_create() than to see several #ifdef
> > >#else #endif in mod_webapp, the portability problems should not be solved
> > in
> > >mod_webapp but in another layer.
> >
> > I agree and that's the main advantage of APR. But you'll see on
> > a Tomcat list question like 'How to build APR ?', 'Where to find a APR.DLL
> > ?'.
>
> This could be the answer:
>
> That means apr.so could/should be downloaded independantly from Apache. (And
> will be in Apache2.0).
