How to resolve LinkageError with JasperReports (6.*)?

Question

e.g. we got:

net.sf.jasperreports.engine.JRException: ...
Caused by: net.sf.jasperreports.engine.fill.JRExpressionEvalException: 
  Error evaluating expression for source text: 
    $P{REPORT_SCRIPTLET}.setTestRaw_LogOn_TstMsgOn(true, true)
Caused by: java.lang.LinkageError: loader constraint violation: loader 
  (instance of java/net/FactoryURLClassLoader) previously initiated loading 
  for a different type with name "org/slf4j/Logger"

running in Eclipse (Kepler) Preview with JR plugin v6.1.0, but not with another Eclipse running with 5.5.1.final

Obviously we are using some build-path-referenced custom report scriptlet which itself is using the slf4j api for logging.

It seems to be conflicting with another different version of the same class (for the same underlying class loading isolation).

Answer 1

I got the same problem and I solved it by adding those Jars in Build path in my project:

• slf4j-api-1.7.12.jar
• slf4j-log4j12-1.7.12.jar
• slf4j-simple-1.7.12.jar

and add also the JasperReports Library and the JasperReports Library Dependencies to the project

with these steps

1. Right click in the project
2. Build Cath > Configure Build Path
3. go to libraries and add the jars using Add External JARs
4. Add the JasperReport Library and JasperReport Library Dependencies using Add Library
5. and then go to Order and Export and check the new added Libraries and Jars and click OK

you will get a result like that :

Answer 2

The easiest solution for us (after some fiddling around with libraries and setup) was to switch back to the Eclipse dir backup version with the Jasper plugin v5.5.1.final (where we still had a copy of for all developers).

It was not easily possible to "Revert" via Eclipse Installation History since either our underlying update site only points to the latest or there may be no old update site for the 5.5.1.final at all. (we did not investigate further)

(btw.: it may be safe to disable auto-updates in Eclipse to avoid such surprises)

Environment details:

(... to the likely causes for the ones who may find other working solutions.)

For us it's the usage of org.slf4j.Logger (having slf4j-api-1.7.5.jar and slf4j-simple-1.7.5.jar in the build path or having both removed - does not matter ... just closing and reopening all reports after changes without Eclipse restarts)

Running Eclipse with the eclipse.ini jvm option -verbose:class shows that the conflict may be related to this other loaded class (whereever it is loaded (maybe used by jasper preview editor itself): eclipse/plugins/org.slf4j.api_1.7.2.v20121108-1250.jar)

I suppose Jasper uses SLF4J since v6 and does not isolate its class loading of report-specific classes/libs with a separate class loader from its own class versions (or the ones provided by the Eclipse installation) and thus such linkage errors (e.g. How to deal with LinkageErrors in Java?.) may be caused.

There is already a known resolved bug with 6.0.4 (where I added these infos) for this, but it obviously is not resolved: http://community.jaspersoft.com/jaspersoft-studio/issues/3831#comment-818386

Answer 3

(Whoo ... finally at least an acceptable workaround for this obviously groovy class loading problem had been found)

We created some very simple helper report hlprep.jrxml that itself

• uses the mentioned scriptlet

  • or would use/call any other java class you would have problems with

• set it to language=java

  • (other sites recommended to switch from language=groovy to java to get rid of the above error, but that is often not an option)

(Now it should run fine in Preview)

Every time you experience this error (it may be random since the class loading may have been correct, depending on what you did before in your IDE) we can now do the following:

1. open the hlprep.jrxml

   • at best with Open with ... JasperReports Preview (so you do not have to explicitely open the Preview in further steps)

2. restart your Eclipse

   • it should remember your open files after restart, otherwise you have to open the helper report first after restart

3. select/preview the hlprep.jrxml

   • now the correct class loading takes place (triggered by the 'java' context)

4. select/preview the (already open) other report(s) that fail(s)

It should run fine now, even after changes, but may fail if you open/close the new ones again. (since the classes may get recycled or the groovy class loader isolation magic loads it differently)

our environment

• Eclipse Neon 3
  • uses Groovy 2.4.5 internally
  • starts with a JDK 1.8.0_121
• Jaspersoft Studio 6.3.2.final
  • we have a 6.3.0 server, but full Neon support was added in 6.3.1 so we took the last patch version of 6.3.x
  • we had issues before where newer studio versions did not work with older servers so we are more careful with upgrades here
• may be irrelevant:
  • it was enough to just depend on the slf4j api (1.7.12 in our case) in the pom.xml
  • we have both provided jasper libraries added to the project: Jaspersoft Server Library, JasperReports Library Dependencies
  • we also depend on server functionality so we also have jasperreports-6.3.0.jar in the pom.xml and some (not via some public Maven repo available) server jars as a User Library to the project (which we copied over from the server)
  • no groovy reference in the pom.xml

Answer 4

A: Sometimes it's enough to just restart Eclipse/Studio. This may be related to some classloaders loading classes when doing certain stuff or using (indirectly) some plugins.

B: Also useful can be, to try to exclude classes/jars that are (explicitely or implicitely) added to the projects classpaths, user lib, Eclipse lib or Mavens pom.xml e.g., if the project itself does not use/need/reference them for design time. This way the conflicts do not occur at design time/in Studio/Eclipse.
Maybe one has to keep in mind then, that those classes/jars/libs may be necessary or different in the runtime environment, which must be solved e.g. via scope in Mavens pom.xml or similar.