On 29.07.2011 12:06, jean-frederic clere wrote:
> [X] Stable - no major issues, no regressions
> [ ] Beta - at least one significant issue -- tell us what it is
> [ ] Alpha - multiple significant issues -- tell us what they are
Detailed results ("-" indicates things which we could improve). Sorry
for the long list, but I didn't check tcnative thoroughly for a long
time. Overall I'm still +1 for stable, because I didn't find
regressions. But there is room for improvement.
+ Tested with Java 1.6.0_26 (but configured against Java 1.5),
APR 1.4.5 and OpenSSL 1.0.1d
+ Platforms Solaris 8+10 Sparc, SLES 10, 32 and 64 Bits,
RHEL 5 64 Bits
+ MD5 OK
- No SHA1, should be added for the future
+ signatures OK
+ key in KEYS file
- KEYS file is contained in the source distribution,
I think it would be better to remove it there, because
people should *not* check the key against one in the untrusted
download.
+ gz and zip for sources consistent
- Except for diferent permissions: zip seems to also contain group
write permissions. Not a real problem, but it's a bit strange
that perms differ between the archive.
Weren't they build on the same system with the same user?
+ source dist consistent with svn tag
- Except for the following pieces missing in the source dist:
- jnirelease.sh
- xdocs (but sources contain docs generated from xdocs)
I suggets for the future we also include the script and the xdocs
to make source dist more complete and self-contained.
- README.txt: is very short (not very helpful).
Also: paths beginning with examples/ miss a leading "jni/"
- native/BUILDING: suggests to "ant echo-example", but it is
"ant run-echo"
- file jni/native/srclib/VERSIONS: what's the reason for this file?
The contents seem outdated and it seems not to get used anywhere
- docs/news could get an update for 2011
- config-guess and config.sub are more recent than the ones
from the APR you crated the source against (good) but still
quite old ('2008-01-23' instead is '2011-06-03'). That's an issue
for people trying to build tcnative on very new platforms,
which are then not detected correctly by those config scripts.
- Binaries build against old APR 1.3.12 (recent ist 1.4.5)
and OpenSSL 0.9.8r (recent ist 1.0.1d).
Is that intentional?
+ recreated release with jnirelease script, results are
consistent with source dist, except for minor expected diffs in
CHANGELOG.txt, build-outputs.mk and generated docs
(whitespace and attribute ordering)
- Warnings during "make":
src/ssl.c: In function 'ssl_rand_make':
src/ssl.c:469: warning: value computed is not used
src/file.c: In function 'Java_org_apache_tomcat_jni_File_writev':
src/file.c:384: warning: pointer targets in assignment differ in signedness
src/file.c:390: warning: pointer targets in passing argument 3 of
'(*e)->ReleaseByteArrayElements' differ in signedness
src/file.c: In function 'Java_org_apache_tomcat_jni_File_writevFull':
src/file.c:418: warning: pointer targets in assignment differ in signedness
src/file.c:428: warning: pointer targets in passing argument 3 of
'(*e)->ReleaseByteArrayElements' differ in signedness
src/network.c: In function 'Java_org_apache_tomcat_jni_Socket_sendv':
src/network.c:668: warning: pointer targets in assignment differ in
signedness
src/network.c:674: warning: pointer targets in passing argument 3 of
'(*e)->ReleaseByteArrayElements' differ in signedness
src/network.c: In function 'Java_org_apache_tomcat_jni_Socket_sendfile':
src/network.c:1220: warning: pointer targets in assignment differ in
signedness
src/network.c:1225: warning: pointer targets in assignment differ in
signedness
src/network.c:1243: warning: pointer targets in passing argument 3 of
'(*e)->ReleaseByteArrayElements' differ in signedness
src/network.c:1247: warning: pointer targets in passing argument 3 of
'(*e)->ReleaseByteArrayElements' differ in signedness
The JNI functions take a jbyte*, which is a signed char* on my Solaris
system. Whereas the iovec iov_base is a caddr_t, which is a char*.
+ make succeds and builds lib
+ all unit tests contained in TC 7 head run successful with
APR connector and this version of tcative
Concerning the Java classes in the source distribution:
- it is unclear to me, why they are still distributed.
Aren't the official sources in trunk/java/org/apache/tomcat/jni?
Note that they are not identical and the tcnative version of the
classes is not maintained any more. So we should no longer distribute
them. Either remove from the distribution, or distribute the TC 7
ones. If we remove them, what about the test and examples classes?
I think they have no other home.
- ant part of build:
- build.xml and build.properties contain version number 1.1.17
- No mentioning of running "ant download" before tests
- ant test fails in lie 85 of SocketServerTestSuite.java, because
on my system the checking for precisely 2 milliseconds won't work.
The call returns after 11 millis not after 2
- ant run-echo: will likely fail, because by default uses privileged
port 23. Maybe switch to 8023? Users should not run tests as root.
- ant run-ssl-server: Could't we include A test certificates in the
test folder? What should the test produce, if run successfully?
- run-echo, run-ssl-server and run-local-server: I couldn't figure
out, what those were actually supposed to show (how they work).
Concerning the famous SSL renegotiation problem:
It is unclear to me, what the current state is. It looks like we support
the unsafe legacy reneg whenever the OpenSSL used during build time
supports it. There is no configuration option to switch it off during
runtime. Right?
Is it correct, that client initiated reneg is not supported and thus the
known attacks will not work even with old OpenSSL?
Should we add a remark about this topic to the announcement?
How do we proceed with TC (various branches): Update required and/r
recommended to 1.1.22?
Finally I'm a bit astonished, that there is no impl for Linux to get
* inf[7] - Idle Time in microseconds
* inf[8] - Kernel Time in microseconds
* inf[9] - User Time in microseconds
*
* inf[10] - Process creation time (apr_time_t)
* inf[11] - Process Kernel Time in microseconds
* inf[12] - Process User Time in microseconds
I implemented those for Solaris long ago ad thought they existed for
Linux from the beginning. But in fact for Linux there are only memory
numbers :(
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
