Crosstab custom incrementer and JBoss hot deployment problem

It's not clear to me what the case is.

 

So redeploying the application results in a new classloader which loads JRIncrementerFactory. But why doesn't this classloader (re)load JRIncrementerFactoryCache as well (in which case the cache would be reinitialized)?

 

I'll try to replicate this in JBoss when time will allow it. In the meantime, post any further information that might help (such as the exception stacktrace, JBoss version, etc).

 

Regards,

Lucian

JBoss version is 5.1.0.GA

jasperreports jar file is in common libraries directory (not in ear), so redeploying ear never changes classloader for jasperreports that's why it keeps "old" JRIncrementerFactory.

packaging jasperreports jar in ear is also workaround for the problem.

Hi,

 

What is the reason for putting JasperReports in the common libraries directory and not in the application EAR?

 

Have you reported this to JBoss? To me it seems more like a classloader problem in JBoss.

 

Thanks,

Teodor

Hi,

as for reasons putting JasperReports not in the EARs (briefly):

there are 15+ EARs on the server and reports (*.jrxml) stored out of EAR (most of them can be modified without redeploying the EAR).

There is the MBean service which generates (compile,fill, export) reports, methods of the MBean called by EARs to generate reports.

 

I'll try to report the issue to JBoss but seems to me the problem is JasperReports' one because java2 in general identifies classes by name and classloader so what your reasons to cache classes by name only?

 

Thanks,

Vitaly

Hi,

I'll try to explain the problem again step by step.

1. system classloader holds JasperReports classes

2. EAR classloader holds the IncrementerFactory classes

3. when generating report JasperReports keeps in cache class from EAR classloader

4. classloader of EAR is not exists in the moment but JasperReports still keeps the class in the cache

5. the EAR may have completely new IncrementerFactory with the same name as it was

6. when JasperReports tries to generate the report it will obtain the OLD IncrementerFactory because they have the same names.

as the result I have either ClasscastException or old version of the IncrementerFactory.

 

I have no idea how JBoss classloading system can fix the problem, so I think it is the JasperReports' one

If you need I can try to create some test EAR to be more specific?

 

Thanks,

Vitaly

A fix has been check into the JR SVN trunk. JRIncrementerFactoryCache now uses weak references to classes as cache keys.

 

SVN log:

Sending work/jasperreports/src/net/sf/jasperreports/engine/fill/JRIncrementerFactoryCache.java

Transmitting file data ...

Committed revision 2994.

 

Regards,

Lucian