Troubleshooting
Problem
Developers of CPE CodeModules that depend on libraries in the application server environment can sometimes experience classloader conflicts when versions of those same libraries or interfaces are bundled with the FileNet CPE EAR file. This note describes some steps that developers and administrators can take to characterize and resolve those conflicts. Some parts of what follows are WebSphere specific, though the concepts can also apply to other application servers.
Diagnosing The Problem
Here is an example of the sort of exception that can occur with this kind of classloader conflict. There are three logical parts to this stack trace. The outermost part is application request handling and the FileNet code in the CPE invoking the event handler (details can vary). The middle part is the custom event handler code implementing its business logic and making a library call. The innermost part is the library code executing and the JVM dynamically trying to load classes in typical Java fashion.
[8/20/14 13:01:41:220 MDT] 000000da SystemOut O 159850 [QueueItemExecutor_fnTestOS2_Worker background task processing0] ERROR com.example.filenet.mycompany.mycompanyIntegrationFacade - com.ibm.ws.websvcs.client.WSClientConfigurationFactory incompatible with org.apache.axis2.jaxws.ClientConfigurationFactory
java.lang.ClassCastException: com.ibm.ws.websvcs.client.WSClientConfigurationFactory incompatible with org.apache.axis2.jaxws.ClientConfigurationFactory
at org.apache.axis2.jaxws.ClientConfigurationFactory.newInstance(ClientConfigurationFactory.java:48)
at org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.getClientConfigurationFactory(DescriptionFactoryImpl.java:438)
at org.apache.axis2.jaxws.description.DescriptionFactory.createClientConfigurationFactory(DescriptionFactory.java:552)
at org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.createServiceDescription(DescriptionFactoryImpl.java:92)
at org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.createServiceDescription(DescriptionFactoryImpl.java:79)
at org.apache.axis2.jaxws.description.DescriptionFactory.createServiceDescription(DescriptionFactory.java:76)
at org.apache.axis2.jaxws.spi.ServiceDelegate.<init>(ServiceDelegate.java:211)
at org.apache.axis2.jaxws.spi.Provider.createServiceDelegate(Provider.java:59)
at javax.xml.ws.Service.<init>(Service.java:57)
at com.example.filenet.mycompany.mycompanyConnection.updateDocument(mycompanyConnection.java:108)
at com.example.filenet.mycompany.mycompanyIntegrationFacade.updateDocInmycompany(mycompanyIntegrationFacade.java:191)
at com.example.filenet.mycompany.mycompanyIntegrationFacade.handlePromoteEvent(mycompanyIntegrationFacade.java:94)
at com.example.filenet.mycompany.mycompanyEventHandler.onEvent(mycompanyEventHandler.java:56)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:94)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:619)
at com.filenet.engine.queueitem.SubscriptionProcessor.executeHandler(SubscriptionProcessor.java:1461)
at com.filenet.engine.queueitem.SubscriptionProcessor.execute(SubscriptionProcessor.java:1227)
at com.filenet.engine.queueitem.EventQueueItemHandler.execute(EventQueueItemHandler.java:102)
at com.filenet.engine.queueitem.EventQueueItemHandler$1.run(EventQueueItemHandler.java:68)
at com.filenet.engine.context.CallState.doAs(CallState.java:217)
at com.filenet.engine.context.CallState.doAs(CallState.java:134)
at com.filenet.engine.queueitem.EventQueueItemHandler.executeAs(EventQueueItemHandler.java:59)
at com.filenet.engine.queueitem.QueueItemExecutor.loadAndExecuteQueuedRow(QueueItemExecutor.java:202)
at com.filenet.engine.queueitem.QueueExecutor.dispatchQueuedRow(QueueExecutor.java:369)
at com.filenet.engine.queueitem.QueueExecutor.dispatchEvent(QueueExecutor.java:203)
at com.filenet.engine.queueitem.QueueExecutor.execute(QueueExecutor.java:127)
at com.filenet.engine.tasks.BackgroundTask.safeExecute(BackgroundTask.java:248)
at com.filenet.engine.tasks.BackgroundTask$BackgroundTaskPriviledgedExceptionAction.run(BackgroundTask.java:1044)
at com.filenet.engine.context.CallState.doAsSystem(CallState.java:417)
at com.filenet.engine.tasks.BackgroundTask.run(BackgroundTask.java:204)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1176)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:853)
Resolving The Problem
Specific troubleshooting steps follow. The order of these items is a suggestion based on experience, but it is not the only order in which to try things. We recommend trying individual steps and checking to see if it resolves the problem (without creating new problems) before moving on to additional steps.
1. The CPE EAR must be deployed and configured with a classloader delgation policy that looks first in CPE classes. On WebSphere, this is called "parent last" classloading policy and can be set via the WebSphere admin console. Navigate to Enterprise Applications -> FileNetEngine -> Class loading and update detection -> Class loader order and verify that it is set to "Classes loaded with local class loader first (parent last)". The EAR classloading policy is normally set correctly by the FileNet configuration manager tool when it deploys the EAR. Verify that it has been set correctly.
2. The Java EE specification details what is included in classloaders for various EAR components, but most application servers provide additional flexibility. WebSphere provides a choice whether to include classes from all web modules in the general EAR classloader or to isolate each web module to its own classloader. Navigate to Enterprise Applications -> FileNetEngine -> Class loading and update detection -> WAR class loader policy and select "Class loader for each WAR file in application". This option will isolate each web module to its own classloader. Although the web modules will still see shared classes within the general EAR classloader with this choice, the CPE server itself will not see classes within the web modules. The most common libraries involved in this conflict are bundled within WAR files within the CPE EAR.
3. (This step applies to WebSphere only and does not apply to other application servers.) Web modules may also have individual classloading policy preferences. For each web module in the CPE EAR, ensure that its classloading policy is also set to "parent last". Navigate to Enterprise Applications -> FileNetEngine -> Manage modules and visit each web module, setting the class loader order to "Classes loaded with local class loader first (parent last)".
4. (This step applies to WebSphere only and does not apply to other application servers.) If the classloading conflict involves subpackages of "com.ibm.xml.xlxp", try removing these JAR files from the CPE EAR /APP-INF/lib/ directory: stax-api.jar, xlxpScanner.jar, and xlxpScannerUtils.jar. The WebSphere JRE already includes classes located within those JARs. NOTE: As of P8 5.2.1, those JARs are no longer included in the WebSphere-specific CPE EAR file.
5. (This step is not recommended unless the other steps fail to resolve the issue.) Instead of packaging your extension code as a CPE CodeModule, put it on the application server classpath. Your event action should still name your Java class in the ProgId property, but it should not point to a CodeModule. That is, the CodeModule property should be null or unset.
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg21689669