Bug 47712 - NoSuchFieldException when trying to use Tomcat Native library
NoSuchFieldException when trying to use Tomcat Native library
Status: RESOLVED FIXED
Product: Tomcat 5
Classification: Unclassified
Component: Catalina
Unknown
PC Linux
: P2 normal with 2 votes (vote)
: ---
Assigned To: Tomcat Developers Mailing List
: PatchAvailable
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2009-08-20 02:52 UTC by Nicolas
Modified: 2010-04-06 16:21 UTC (History)
1 user (show)



Attachments
Get Fields before switching to different clazz. (1.44 KB, patch)
2009-10-23 12:57 UTC, Rainer Jung
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas 2009-08-20 02:52:57 UTC
I tried to add the Tomcat Native library to tomcat 5.5.28.
After compiling the library and configuring tomcat to use it, I still got the same message (the library is not found).
I changed the log level to finest for the class org.apache.catalina.core.AprLifecycleListener to get more details about the problem and I got:
java.lang.NoSuchFieldException: TCN_MAJOR_VERSION
	at java.lang.Class.getField(Class.java:1507)
	at org.apache.catalina.core.AprLifecycleListener.lifecycleEvent(AprLifecycleListener.java:91)
	...

When I looked the source code (5.5.28), I can see that the lifecycleEvent function does:
1. load the class org.apache.tomcat.jni.Library into the variable clazz
2. invoke 'initialize' on clazz
3. load the class org.apache.tomcat.jni.SSL into the same variable clazz
4. invoke 'randSet' on clazz
5. get field 'TCN_MAJOR_VERSION' of clazz (line 91)

The step 5 throws the exception: there is no field TCN_MAJOR_VERSION in org.apache.tomcat.jni.SSL.

I guess that this field should be retrieved from org.apache.tomcat.jni.Library, not org.apache.tomcat.jni.SSL (move step 5 before step 3)

Cheers,
Nicolas
Comment 1 Roy Robinson 2009-08-24 09:17:08 UTC
Description: Blocks use of the native tomcat i/o library (tcnative)
Tomcat version: 5.5.28
Platforms:  PC, Windows and Linux

I found this defect independently; I'd like to confirm it and Nicolas's analysis. It absolutely prevents using the native library. I'd also recommend changing the very misleading (i.e., wrong) message that appears when not operating in DEBUG level. Just moving the getField invocations ahead of the org.apache.tomcat.jni.SSL code fixes the problem.

Here's the ed script for the path:

91,93d
83a

                major = clazz.getField("TCN_MAJOR_VERSION").getInt(null);
                minor = clazz.getField("TCN_MINOR_VERSION").getInt(null);
                patch = clazz.getField("TCN_PATCH_VERSION").getInt(null);
.


Thanks.

Roy
Comment 2 Joe Dane 2009-10-23 10:42:28 UTC
Consider this another vote for someone to take a look at this extremely irritating bug.  Tomcat will simply and quietly fail to use apr as long as this remains unfixed.
Comment 3 Rainer Jung 2009-10-23 12:56:06 UTC
Sorry this got broken in 5.5.28.
I proposed the attached patch for inclusion in the next version.
Comment 4 Rainer Jung 2009-10-23 12:57:45 UTC
Created attachment 24411 [details]
Get Fields before switching to different clazz.
Comment 5 Rainer Jung 2009-11-02 17:25:48 UTC
Applied to TC 5.5.x as r832245.
Will be part of 5.5.29.