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

Issue

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).

Solution

(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

Answered By - Andreas Covidiot
Answer Checked By - David Goodson (JavaFixing Volunteer)