Unable to use Apache POI - getting SchemaTypeLoaderException

Question

I'm trying to use Apache POI (3.10 or 3.15) with XpertIvy Designer v5.0.18 and I'm getting the following exception:

SchemaTypeLoaderException: XML-BEANS compiled schema: Incompatible minor version - expecting up to 23, got 24 (schemaorg_apache_xmlbeans.system.sE130CAA0A01A7CDE5A2B4FEB8B311707.index) - code 3
java.lang.reflect.InvocationTargetException
RuntimeException: Could not instantiate SchemaTypeSystemImpl (java.lang.reflect.InvocationTargetException): is the version of xbean.jar correct?

I saw a few older threads (POI conflicted xmlbeans.jar [2014] or what is axis lib used for [2015]) regarding this issue.

Is it really true that you still have to hack the designer plugins folder and some server folder too???

Accepted Answer

In short: The hack is no longer required. Since 6.6.1 POI can be used in a project without any library conflicts at runtime.

Axon.ivy 6.6.1 and younger

These kinds of JAR hell issues are gone from 6.6.1 upwards.

In the Designer many libraries were removed from the Axon.ivy Classpath container. Practically this means that Webservice Process (CXF) and Webservice Call (AXIS2) libraries are no longer on the classpath of the project. And as xmlbeans is a dependency of CXF, the conflict with POI is gone. These old libraries can be added to classpath manually in the preferences, if anyone used them to patch AXIS stubs or by accident. http://developer.axonivy.com/doc/latest/DesignerGuideHtml/ivy.processmodeling.html#ivy.project.preferences.java

The Engine is now also delivered as OSGI version. This means that the proper ClassLoader isolation per Bundle behaves as it does in the Designer. So a huge runtime behavior difference is gone since 6.6.1. The OSGI Engine will become the default version of the Engine. We do not plan to support the OS specific packages any longer due its classloading shortcomings. But for a short time we still release the alternative packages that can be used if you face migration issues.

Axon.ivy 6.5.0 and older

The ugly workaround is still required.

Designer: manually patch the JAR in the plugins directory.
Engine: rename the /lib/shared/xmlbeans_2.4.0.jar to somethink like xmlbeans_2.4.0.jar.deactivated

Answer 2

0

You could try to work around the problem by setting a ThreadContextClassloader in the area where you access POI code.

ClassLoader oldTcl = Thread.currentThread().getContextClassLoader();
try
{
  Thread.currentThread().setContextClassLoader(APoiClass.class.getClassLoader());
  // ANY POI INVOKER CODE
}
finally
{
  Thread.currentThread().setContextClassLoader(oldTcl);
}

Maybe this makes engine and designer hacks obsolete.

link

answered 18.11.2016 at 15:11

Reguel Werme... ♦♦
9.4k●3●19●58
accept rate: 70%

Once again it's been a while until I found some time to test your workaround, sorry.

I've tried it with the newest POI 3.16 (poi, poi-ooxml, poi-ooxml-schemas, poi-scratchpad jar files on the build path) but it didn't work out. I've put the logic to create a word file into a seperate class file (not inside an ivy script block etc). Inside the constructor I've added the try / catch block you noted. The failing expression is XWPFDocument doc = new XWPFDocument();.

Any other ideas?

(30.05.2017 at 10:43) Oliver

The latest Axon.ivy 6.6.1 can run and isolate your POI libraries without any additional hacking. So you could plan a migration.

The only way out for 5.0 is to repackage POI and all its dependencies into one FAT-JAR that contains all classes to run it. There are several tools that support repackaging. See http://repackage.org. But unfortunately google already lists some forum posts of users that failed to repackage POI.

(31.05.2017 at 09:20) Reguel Werme... ♦♦

Unable to use Apache POI - getting SchemaTypeLoaderException

Follow this question

Related questions