classLoading issues in JR (at least since 3.1.4)

[pbakker]

Hi,

We have an implementation using JasperReports since version 2.x and all has been working fine.

Recently we tried upgrading to the latest version (first 3.1.4 and then 3.5) but this has caused us issues in some scenario's. We were getting errors like the following:

2009-04-07 11:10:39,750 ERROR [http-8080-1] org.apache.commons.digester.Digester - Begin event threw exception
java.lang.ClassNotFoundException: net.sf.jasperreports.engine.xml.JasperDesignFactory
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1358)
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1204)
    at org.apache.commons.digester.FactoryCreateRule.getFactory(FactoryCreateRule.java:489)
    at org.apache.commons.digester.FactoryCreateRule.begin(FactoryCreateRule.java:389)
    at org.apache.commons.digester.Digester.startElement(Digester.java:1361)
    at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
    at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
    at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
    at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
    at org.apache.commons.digester.Digester.parse(Digester.java:1647)
    at net.sf.jasperreports.engine.xml.JRXmlLoader.loadXML(JRXmlLoader.java:239)
    at net.sf.jasperreports.engine.xml.JRXmlLoader.loadXML(JRXmlLoader.java:226)
    at net.sf.jasperreports.engine.xml.JRXmlLoader.load(JRXmlLoader.java:214)
    at net.sf.jasperreports.engine.xml.JRXmlLoader.load(JRXmlLoader.java:168)
    at net.sf.jasperreports.engine.xml.JRXmlLoader.load(JRXmlLoader.java:152)

.....

We have traced this back to how JR loads it's classes.  We were able to work around this specific error by clearing the classLoader of the current thread before calling the JR code that caused this error:

ClassLoader cl = Thread.currentThread().getContextClassLoader();
            if (tempFile.exists())
            {
                try {
            Thread.currentThread().setContextClassLoader(null);
            JasperDesign jasperDesign = JRXmlLoader.load(reportSource);
            jasperReport = JasperCompileManager.compileReport(jasperDesign);
            } finally {
            Thread.currentThread().setContextClassLoader(cl);
            }
            } else {
                throw new RemoteException("No jasperReport " + report + " has been found or loaded in directory " + jasperDirectory);
            }

Allthough we can fix the issue this way, I think there's something wrong in the JR code.

Once we had fixed the issue above with the described workaround, we ran into the next error:

2009-04-07 11:13:06,296 ERROR [http-8080-2] com.servoy.j2db.util.Debug - Throwable
net.sf.jasperreports.engine.JRRuntimeException: No query executer factory registered for the 'SQL' language.
    at net.sf.jasperreports.engine.util.JRQueryExecuterUtils.getQueryExecuterFactory(JRQueryExecuterUtils.java:67)
    at net.sf.jasperreports.engine.fill.JRFillDataset.createQueryDatasource(JRFillDataset.java:672)
    at net.sf.jasperreports.engine.fill.JRFillDataset.initDatasource(JRFillDataset.java:596)
    at net.sf.jasperreports.engine.fill.JRBaseFiller.setParameters(JRBaseFiller.java:1223)
    at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:853)
    at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:802)
    at net.sf.jasperreports.engine.fill.JRFiller.fillReport(JRFiller.java:63)
    at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:421)

.....

We managed to fix this by implementing our workaround around a larger block of code.

We are getting these issues in the scenario in which everything runs within a Tomcat environment. when we execute the exact same code when not running within a Tomcat environment, all works fine.

We are using the latest JR 3.5 jar (downloaded 07-04-09).

Hope someone can shed some light on this soon.

P.

[prkothan]

 We too hitting the same set of problems.

1. Class loading problem. Applied the same fix.

Now the same SQL related exception.

 

Please help.

 

Regards,

Prasanna

[lucianc]

The first error seems to occur when the thread context class loader cannot resolve JR classes.  Could you confirm this?  Also, could you explain a use case when this would happen?  Having a context class loader that does not know about classes used in the application seems a little strange..

In any case, I think that a proper workaround for this is to do Thread.currentThread().setContextClassLoader(JasperDesign.class.getClassLoader()) instead of Thread.currentThread().setContextClassLoader(null).  This would take care of the built-in extensions and fix the "no such query executer" error.

Also log this as a bug so that we'll analyze it and come up with some resolution to it.

Regards,

Lucian

[nmacke]

Hi, I have the same SQL problem where czn I find the solution ?

[lucianc]

This was fixed in JR 3.5.1.  See http://jasperforge.org/projects/jasperreports/tracker/view.php?id=3832 for details.

Regards,

Lucian