tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: tcnative API stability/compatibility
Date Thu, 01 Jan 2009 17:46:54 GMT
On 01.01.2009 18:15, Mark Thomas wrote:
> Rainer Jung wrote:
>> Concerning the native side. What is the compatibility goal between the
>> Java code and the native lib? Do we want to urge each using software to use
>>
>> a) exactly the same version of native, than the version of the Java code
>> b) the same minor version, but patch version greater or equal to the
>> Java side
>> c) the same major version and any minor/patch greater or equal ...
>>
>> I guess we want a) or b), I think it's to early for c).
>>
>> If we go for b) and trunk is for a 1.2.x version, we don't need to
>> support loading multiple copies of the native library. So I guess, b) is
>> what we should do?
> b) seems like a sensible target given I don't know how much work c)
> would be.
>
> Now is probably a good time to extract the native library into a
> separate component (ie move tomcat/connectors/trunk/jni/native/
> to tomcat/native etc) and treat it as an external library rather than
> using svn externals. ie add tcnative to the list of libs downloaded as
> part of the build process.

We need to have a better idea on the future relation between the Java 
code in jni and the native code. Is our goal providing jni native 
function implementations (with stability docs etc.) or is the goal more 
providing a Java API which is backed by the native implementation.

Until now I think tcnative inside Tomcat is only used via the Java API 
in org/apache/tomcat/jni. If this API is our primary target, then we 
should think about moving the native and the Java part of tcnative and 
releasing them together.

Do we think that we will loose flexibility on the Tomcat side by this?

At the monent we have copies of the Java classes in TC trunk and TC 6, 
but it looks like we didn't yet use those copies for quicker fixes, 
instead the copies missed fixes we applied to tcnative directly.

What's the feeling:

a) bundling native and org/apache/tomcat/jni code in one place in svn 
and releasing together

or

b) separating only the native implementation

In case of a):

Do we want to delete the copies of org/apache/tomcat/jni in TC trunk and 
6.0.x and use instead ones downloaded from a tcnative release or an svn 
external to the new tcnative svn location?

I tend to suggest a) and also getting rid of the redundant copies of the 
classes in TC trunk and 6, but I'm not sure if I noticed all implications.

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message