Bug 51523 - ClassNotFoundException when loading TLD listeners
Summary: ClassNotFoundException when loading TLD listeners
Status: RESOLVED INVALID
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Catalina (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-18 09:32 UTC by Alonso
Modified: 2011-07-19 17:00 UTC (History)
0 users



Attachments
Localhost log file (1.96 KB, application/octet-stream)
2011-07-18 09:32 UTC, Alonso
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alonso 2011-07-18 09:32:17 UTC
Created attachment 27296 [details]
Localhost log file

Tomcat 7 fails to find listener class defined in TLD.

Tag library is packaged inside folder "META-INF" of one the libraries deployed with the webapp. Tomcat seems to read perfectly the tag library definition but throws a "ClassNotFoundException" when trying to invoke the listener class, which exists and it's contained in same jar file as the tag library definition.

Same application starts up perfectly with Tomcat 6.x.
Comment 1 Mark Thomas 2011-07-19 13:47:15 UTC
This works for me with a simple test case and I'd be surprised if the TCKs didn't cover this as well (although I haven't checked).

This is most likely a configuration error, possibly an issue with the TLD and/.or web.xml since Tomcat 7 is stricter about validating these.
Comment 2 Alonso 2011-07-19 13:54:41 UTC
I should be more specific in my previous post. As you can see at logfile the exception message is:

java.lang.ClassNotFoundException: 
            net.sf.jasperreports.jsf.config.ConfigurationStartupListener

and the listener definition in TLD is as follows:

<listener>
    <listener-class>
        net.sf.jasperreports.jsf.config.ConfigurationStartupListener
    </listener-class>
</listener>

So, Tomcat 7 is not trimming blanks at the string which has been read from the TLD file. I think it should be considered as a bug no matter how stricter Tomcat 7 had become validating the TLD file, since TLD is still valid with or without those blanks.
Comment 3 Mark Thomas 2011-07-19 14:12:24 UTC
This works for me with the blanks present as well.

This still looks like a configuration error and the users list is the place to get help.
Comment 4 Alonso 2011-07-19 14:29:12 UTC
Sorry for being so pedant, but I'm not asking for help, I'm reporting a bug because if I modify the TLD inside the jar file (removing blanks), repack it and deploy the same webapp with the modified jar, then the application is started up without problems. I didn't posted previously whithout check that first.

Please, review the code at the component which loads TLD files since I'm pretty sure that it is not trimming blanks a that string.

I'm using Tomcat 7.0.16 and this library:
https://sourceforge.net/projects/jasperreportjsf/

Kind regards.
Comment 5 Mark Thomas 2011-07-19 15:49:55 UTC
Hmm. I still can't reproduce this even with that library.

Trying with 7.0.16 rather than trunk...

That reproduced it. Very odd. I don't recall any changes since 7.0.16 that fixed this. Trying with 7.0.19. That also reproduces it... Even stranger. The changes between 7.0.19 and trunk are minimal and seem unrelated to this. Still digging...
Comment 6 Mark Thomas 2011-07-19 17:00:09 UTC
Tracked it down.

The TLD provided by the JAR you are using is invalid. If you follow the definitions in the XSDs you'll eventually see that leading and trailing whitespace should not be present.

Since this is an invalid TLD Tomcat will not be adding a work-around for this. Tomcat very rarely adds workarounds for bugs in third-party applications/libraries.

The reason I wasn't seeing it is that I always run Tomcat with -Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE="true"
Amongst other things, this configures the XML parsers to use the slower but specification compliant settings of validation=true and namespaceAware=true. With these settings the parsers remove leading and trailing whitespace.

One work-around that is available to you is to enable STRICT_SERVLET_COMPLIANCE or configure appropriate XML validation for the specific context. Help with either of those options is available on the users mailing list.