Need help with ClassNotFoundException (EMC/Documentum - modules?)

[johnson_shawn]

I'm moving to JBoss 7 from another app server, and I've worked through some issues, but having some trouble working out this issue.  We use EMC Documentum - DFC.  Currently I have all of the jar files in WEB-INF/lib, which works fine on JBoss 5.1 as well as OC4J.  I've tried various things, including creating a module: com.documentum with all the dependent jars, and added that dependency to my jboss-deployment-structure.xml.  It seems odd to me that I can't keep these libraries in WEB-INF/lib if they are only needed within the WAR?

19:18:50,087 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"JBAS014671: Failed services" => {"jboss.web.deployment.default-host./MY_WAR" => "org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./MY_WAR: JBAS018040: Failed to start context"}}}}

19:18:54,627 ERROR [stderr] (Session pool worker) Exception in thread "Session pool worker" java.lang.NoClassDefFoundError: com/documentum/fc/client/content/impl/LocalContentManager

19:18:54,628 ERROR [stderr] (Session pool worker)      at com.documentum.fc.client.impl.session.Session.disconnect(Session.java:245)

19:18:54,629 ERROR [stderr] (Session pool worker)      at com.documentum.fc.client.impl.session.SessionPool.disconnectSessions(SessionPool.java:111)

19:18:54,635 ERROR [stderr] (Session pool worker)      at com.documentum.fc.client.impl.session.SessionPool.flush(SessionPool.java:134)

19:18:54,636 ERROR [stderr] (Session pool worker)      at com.documentum.fc.client.impl.session.SessionPool.flushAllPools(SessionPool.java:190)

19:18:54,636 ERROR [stderr] (Session pool worker)      at com.documentum.fc.client.impl.session.SessionPool$ExpirationThread.run(SessionPool.java:246)

19:18:54,637 ERROR [stderr] (Session pool worker) Caused by: java.lang.ClassNotFoundException: com.documentum.fc.client.content.impl.LocalContentManager from [Module "deployment.MY_WAR.war:main" from Service Module Loader]

19:18:54,637 ERROR [stderr] (Session pool worker)      at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)

19:18:54,638 ERROR [stderr] (Session pool worker)      at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)

19:18:54,638 ERROR [stderr] (Session pool worker)      at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)

19:18:54,639 ERROR [stderr] (Session pool worker)      at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)

19:18:54,639 ERROR [stderr] (Session pool worker)      at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)

19:18:54,640 ERROR [stderr] (Session pool worker)      at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)

19:18:54,640 ERROR [stderr] (Session pool worker)      ... 5 more

I also followed this:  https://docs.jboss.org/author/display/AS71/Developer+Guide#DeveloperGuide-HowtofindtheJBossmoduledependency - but I'm not sure I was able to do anything with the dependency reports from tattletale.

com.documentum module

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="com.documentum">
  <resources>
        <resource-root path="activation.jar"/>
        <resource-root path="All-MB.jar"/>
        <resource-root path="aspectjrt.jar"/>
          <resource-root path="certjFIPS.jar"/> 
          <resource-root path="configservice-api.jar"/>
          <resource-root path="configservice-impl.jar"/>
           <resource-root path="dms-client-api.jar"/>
           <resource-root path="jaxb-api.jar"/>
           <resource-root path="jaxb-impl.jar"/>
           <resource-root path="jsafeFIPS.jar"/>
           <resource-root path="jsr173_api.jar"/>
           <resource-root path="log4j.jar"/>
           <resource-root path="xtrim-api.jar"/> 
           <resource-root path="xtrim-server.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
  </dependencies>
</module>

jboss-deployment-structure.xml

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
  <deployment>
    <dependencies>
      <module name="com.myapp.settings" />
      <module name="com.documentum" />
    </dependencies>
  </deployment>
</jboss-deployment-structure>

[sfcoy]

It should work properly when you place all documentum jars in your WEB-INF/lib directory.

I suspect you are having issues because of the redundant jars that you have listed in your module:

• activation.jar
• jaxb-api.jar
• jaxb-impl.jar
• jsr173_api.jar

Theses jars all provide classes that are part of Java SE 1.6+ these days and they will collide. Furthermore, JEE6 mandates an even newer version of JAXB (2.2) than that provided by the standard Java runtime.

You could also make a case for removing log4j as this is also provided in AS7.

Try your WAR only deployment again after removing these 4 (or 5) jars.

[johnson_shawn]

Thanks Stephen.  I removed those jars from my WEB-INF/lib and removed the module reference from my jboss-deployment-structure.xml.  Still getting the same class not found error.  I have quite a few other Jar files in my WEB-INF/lib.

I kept log4j for now because my project likes that for compile.  Don't want to get too far off subject, but should I point to the JBoss log4j library, or keep a copy in my project outside of the WAR structure?  Did I mention this is all running in eclipse using the JBoss tools?

Is there something else along the lines of the tattle tale scan that I should use to check for other Jars that I might need to remove from my WAR because they are already included by the container?  I do see that I have resteasy Jars, which are a slighly older version than those I'm finding under /modules.

[sfcoy]

The general rule is to not deploy jars that provide APIs or implementations that are already mandated by the JEE6 spec and provided by the server. RestEASY falls into that bucket so you can leave that out too. The various XML parsers such as xerces, xalan etc can also cause problems. If you have xml-apis.jar it is another common culprit.

If you list the jars out here we can probably identify the ones that should be removed.

You do need to identify the jar that contains com/documentum/fc/client/content/impl/LocalContentManager.class so that you can be sure that it is present.

[johnson_shawn]

These are the 3rd-party JARS included in our WEB-INF/lib folder:

1. aopalliance.jar
2. aspectjrt.jar *
3. aws-java-sdk-1.1.9.jar
4. certjFIPS.jar *
5. commons-codec-1.6.jar
6. commons-fileupload-1.2.2.jar
7. commons-httpclient-3.1.jar
8. commons-io-2.0.1.jar
9. commons-lang-2.4.jar *
10. commons-logging-1.1.1.jar
11. concurrent.jar
12. configservice-api.jar *
13. configservice-impl.jar *
14. dfc.jar *
15. endeca_logging.jar
16. endeca_navigation.jar
17. guice-3.0.jar
18. guice-assistedinject-3.0.jar
19. guice-servlet-3.0.jar
20. gwt-log-3.1.7.jar
21. gwt-servlet-deps.jar
22. gwt-servlet.jar
23. gwtp-all-0.6.jar
24. gwtupload-0.6.4-SNAPSHOT.jar
25. gxt-2.2.3-gwt22.jar
26. gxt-3.0.2.jar
27. jackson-core-asl-1.8.5.jar
28. javassist-3.8.0.GA.jar
29. javax.inject.jar
30. jaxrs-api-2.3.1.GA.jar
31. jcifs-krb5-1.3.1.jar *
32. jcs-1.3.jar
33. jettison-1.3.1.jar
34. jsafeFIPS.jar *
35. krbutil.jar *
36. log4j-1.2.16.jar
37. recaptcha4j-0.0.7.jar
38. resteasy-guice-2.3.1.GA.jar
39. resteasy-jettison-provider-2.3.1.GA.jar
40. scannotation-1.0.3.jar
41. urlrewrite-3.2.0.jar
42. xtrim-api.jar *
43. xtrim-server.jar *

#14 - dfc.jar contains com/documentum/fc/client/content/impl/LocalContentManager.class

* Libs pulled in for Documentum/DFC

(thanks so much for your help so far Stephen)

[sfcoy]

Only 29 (javax.inject.jar) and 30 (jaxrs-api-2.3.1.GA.jar) stick out to me. You can safely remove those.

Are you still getting exactly the same CNFE after this?

If so you may need to download a tool like JD-GUI and disassemble dfc.jar to see what dependencies this class has. You can sometimes get CNFE on classes that are present, but their dependencies are not. This can include implemented interfaces, super classes and static initialisers.

[sfcoy]

Also, is it possible that gwtp-all-0.6.jar includes the same content as the other gwt-*.jars? If that is the case you should remove one or the other.

[johnson_shawn]

I decided to try a slimmer project, and just have GWT and DFC in there.  I thought it might be nice to have a DFC module, so I played with that for a while.  I knew the dfc.jar had a number of Jars referenced in its Manifest, so I took the full set of JARs included from EMC and dumped them into a module...well, actually I did that AFTER I realized that I had somehow been missing the one key file - dfc.jar - how it got lost I don't know?

This got me a bit further along.  I ran into some log4j complaints, so I commented out the log4j.jar from the com.documentum module.xml and added a dependency to org.apache.log4j.

Next CMFE was for javax.transaction - so I added that, and I seem to have made it through the Documentum related errors.  Here is my com.documentum module.xml

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="com.documentum">
  <resources>
          <resource-root path="All-MB.jar"/>
          <resource-root path="DmcRecords.jar"/>
          <resource-root path="activation.jar"/>
          <resource-root path="aspectjrt.jar"/>
          <resource-root path="bpmutil.jar"/>
          <resource-root path="certjFIPS.jar"/> 
          <resource-root path="ci.jar"/>
          <resource-root path="collaboration.jar"/>
          <resource-root path="commons-codec-1.3.jar"/>
          <resource-root path="commons-lang-2.4.jar"/>
          <resource-root path="configservice-api.jar"/>
          <resource-root path="configservice-impl.jar"/>
          <resource-root path="dfc.jar"/>
          <resource-root path="dms-client-api.jar"/>
          <resource-root path="jaxb-api.jar"/>
          <resource-root path="jaxb-impl.jar"/>
          <resource-root path="jcifs-krb5-1.3.1.jar"/>
          <resource-root path="jsafeFIPS.jar"/>
          <resource-root path="jsr173_api.jar"/>
          <resource-root path="krbutil.jar"/>
          <!-- <resource-root path="log4j.jar"/> -->
          <resource-root path="messageArchive.jar"/>
          <resource-root path="messageService.jar"/>
          <resource-root path="subscription.jar"/>
          <resource-root path="workflow.jar"/>
          <resource-root path="xtrim-api.jar"/> 
          <resource-root path="xtrim-server.jar"/>
  </resources>
  <dependencies>
            <module name="org.apache.log4j"/>
            <module name="javax.transaction.api"/>
    <module name="javax.api"/>
  </dependencies>
</module>

[sfcoy]

OK, it's good to see you're getting somewhere.

Now I'd remove the activation, jsr173_api and jaxb jars and add these dependencies:

{code:xml}<module name="javax.xml.bind.api" />
<module name="javax.ws.rs.api" />
<module name="javax.inject.api" />
<module name="javax.xml.stream.api" />{code}

[ywbanm]

Hi, do you get dfc works with JBoss7.

I always got exception for can not found dfc.properties,

Coud you guide me how config these properties on JBoss7?

Thanks!

[johnson_shawn]

Zehao, I do have DFC working with JBoss 7.  The dfc.properties should either go in your WEB-INF/classes or in a 'settings module'.  I have put what I learned into an article for future reference.

Using EMC Documentum DFC with JBoss 7

[ywbanm]

Hi Shawn,

Thank you for your article, I did DFC working with JBoss7, cheers!

But dfc.properties still can't be found even I created a 'setting module',

My module.xml:

<?xml version="1.0" encoding="UTF-8"?>

<module xmlns="urn:jboss:module:1.1" name="com.documentum.config">

  <resources>

                      <resource-root path="."/>

  </resources>

</module>

But if I added the property to system-properties on standalone.xml that could resolved that problem.

<property name="dfc.properties.file" value="C:\jboss-as-7.1.1.Final\modules\com\documentum\config\main\dfc.properties"/>

Thanks you again!

zehao

[johnson_shawn]

Did you add both modules to your jboss-deployment-structure.xml?

So, based on your config/settings module name, I would expect this:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
          <deployment>
                    <dependencies>
                              <module name="com.documentum.config" />
                              <module name="com.documentum" />
                    </dependencies>
          </deployment>
</jboss-deployment-structure>

[ywbanm]

yes, I did that.

<jboss-deployment-structure>

  <!-- Make sub deployments isolated by default, so they cannot see each others classes without a Class-Path entry -->

  <ear-subdeployments-isolated>false</ear-subdeployments-isolated>

  <!-- This corresponds to the top level deployment. For a war this is the war's module, for an ear -->

  <!-- This is the top level ear module, which contains all the classes in the EAR's lib folder     -->

  <deployment>

    <!-- Exclusions allow you to prevent the server from automatically adding some dependencies     -->

    <!-- <exclusions>

        <module name="org.javassist" />

    </exclusions> -->

          <exclusions>

            <module name="org.apache.log4j"/>

    </exclusions>

    <!-- This allows you to define additional dependencies, it is the same as using the Dependencies: manifest attribute -->

    <dependencies>

       <module name="com.documentum.config" />

       <module name="com.documentum" />

    </dependencies>

    <!-- These add additional classes to the module. In this case it is the same as including the jar in the EAR's lib directory -->

    <resources>

      <!-- resource-root path="my-library.jar" / -->

    </resources>

  </deployment>

</jboss-deployment-structure>