1 Reply Latest reply on Aug 15, 2016 11:50 AM by milspec

    Migration: Odd Classloading/Class problem in Wildly10

    milspec

      Hi all,

       

      Problem

      Wildfly 10 has a class definition/class loading problem which we never saw in Jboss4.

       

       

      Caused by: java.lang.RuntimeException: WFLYSRV0177: Error getting reflective information for class org.apache.struts.action.ActionServlet with ClassLoader ModuleClassLoader for Module \"deployment.app.ear:main\" from Service Module Loader
      Caused by: java.lang.ClassFormatError: Failed to link org/apache/commons/collections/FastHashMap (Module \"deployment.app.ear:main\" from Service Module Loader): Extra bytes at the end of class file org/apache/commons/collections/FastHashMap"},

       

      So the problem looks like a bad .class file. Fair enough

       

      However

      In order to isolate the .class file, I found the three jars that contain FastHashMap.class and wrote a small bash script to sniff it out, i..e compiling against and instantiating FastHashMap.

       

      fwiw, here are the jars:

      • commons-beanutils-1.7.0.jar
      • commons-collections-3.1.jar
      • checkstyle-all-4.2.jar

       

      To my surprise, javac and java liked the FastHashMap.class in each of the jar files for both jdk7 and jdk8.

       

      This makes me wonder: does wildfly load the .class file differently than 'plain old java'?

       

      Here is the script:

      #!/bin/sh

      myclass=TestFastHashMap

      for myjar in commons_collections_jars/*.jar

      do

          echo $myjar

          echo javac -classpath $myjar ${myclass}.java

          javac -classpath $myjar ${myclass}.java && \

          echo compile ok && \

          echo java -classpath "$myjar:." ${myclass} && \

          java -classpath "$myjar:." ${myclass} || \

              echo problem $myjar

                  

      done

       

       

          

      Questions

      • What am I missing?
      • Why does javac and java load the .class file whereas wildfly fails?
      • does wildfly load the .class file differently than 'plain old java'? [yes, i have the source code and can look myself]
      • How can I find the from which Wildfly tries to load the problem class. (I tried "-verbose:class") but because the classloader did not successfully load the class, it does not appear
      • Does Wildfly have even more classloader debugging, i.e. similar to this in jboss4?
      <category name="org.jboss.mx.loading" additivity="false">
          <priority value="TRACE" class="org.jboss.logging.XLevel"/>
          <appender-ref ref="UCL"/>
      </category>
        • 1. Re: Migration: Odd Classloading/Class problem in Wildly10
          milspec

          I found the root cause.

           

          This jar contained two copies of the class FastHashMap

               checkstyle-all-4.2.jar

           

          After taking a break from this issue, i took a fresh look at it today and wrote a quick brute-force script to find the problem class.

           

          I stumbled across this 'duplicate class within the jar file' issue while unzipping all the jar files --the 'unzip' command complained whereas 'jar xf' did not

           

          Why did wildfly err but jboss4 did not?

           

           

          It looks like I introduced the issue in well-meaning, but ignorant error

           

          In migrating to wildfly, I 'cleaned up' the manifest/filesystem by moving everything to 'app.ear/lib'. Wildfly would then automatically include these files, regarldess of the ejb.mf.

           

          On our jboss-4 instance, the filesystem had this jar file, but the ejb manifest did not....considerable cruft and mismatch between the two.