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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
