tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: [APR-JAVA] cvs upload
Date Fri, 14 Jan 2005 07:38:57 GMT
At 01:25 AM 1/14/2005, Mladen Turk wrote:
>Costin Manolache wrote:
>>To be honest, I don't like where this is going. I think access to native
>>functionality for tomcat is great - and starting with functionality provided by apr
is ok. But there is a lot outside apr, and if this becomes 'apr - java interface', it won't
be easy to add.
>I agree with you. After all, the main focus is Tomcat support,
>as APR's main focus is Httpd support.

Outch!  Hope that isn't the worldwide impression;

Other portability-related issues are also welcomed, discussed
and oftentimes adopted!  For example - multicast is fairly
useless to http: scheme, but development of multicast is lively 
and progressing well, and is subject to tcp/ip implementation
quirks and deviations.

Yes it sprouted from httpd's portability needs, but work continues
apace and it's been a -long- time since I heard the refrain "We
don't need to do that, it's not required by httpd."  That train
of thought gets slapped down fast :)

However, apr isn't a dumping ground.  If the concern isn't really
portability, but more akin to library wrappers and so on, those
items end up in the apr-util (dumping ground) of nice-to-have
sorts of features, or sometimes dismissed out of hand.

>One of the goals is to add openssl support, as well as witting
>Servlet API four using by legacy applications (like module interface
>for httpd).
>Perhaps my posts led to wrong presumption that this is only JNI
>wrapper over APR library.

Probably my confusion.

>>So maybe it would be better to rename it to org.apache.tomcat.jni or something, keep
the apr stuff as 'tomcat interface with apr' ( with a comment that when/if apr does have an
official binding - we can switch), and keep it open for the other non-apr stuff that may be
>Sure, org.apache.tomcat.jni would be fine, and even better reflect the
>purpose of the package.

Clearly, your interface will be broader than apr.  When you do
encounter the need for abstracting apr specifically, I do hope
you consider doing this in a concerted effort.  A reply to my
post on, that an oo-dev abstraction effort
is worthwhile, wanted, or you want to participate in, would
be most appreciated.


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

View raw message