1 Reply Latest reply on Jul 8, 2004 7:17 AM by gratcliffe

    JBoss ClassLoader hell. Please help.

    mredington

      We have an application that runs fine under tomcat standalone (4.1.30)

      However, when we try and run it under jboss (3.2.3), we get a class conflict.

      We are using the latest version of the jfreegraph classes in our app. Older versions of the jfreegraph classes are also present in jboss 3.2.3. When we try and call the new jfreegraph methods, we get a NoSuchMethodError exception, as our app is seeing jboss's versions of the class. Not our latest versions.

      So, we have been trying to configure our app to use its own jfreegraph classes, rather than the server's. This seems to be possible in principle, but we are struggling to get the configuration correct.

      Our app is packaged as a .war file, inside an .ear

      We have an application.xml, and a jboss-app.xml inside the .ear file. The jboss-app.xml contains the entry

      <loader-repository>
       net.star-map.clv:loader=clv.ear
       <loader-repository-config>
       java2ParentDelegation=false
       </loader-repository-config>
      </loader-repository>
      


      Our .war file contains a manifest.mf, which points at our jars, which are in a lib directory, inside the .war file.

      We have also changed the UseJBossWebLoader entry in server/default/deploy/jbossweb-tomcat41.sar/META-INF/jboss-service.xml to read 'false'

      We have tried a lot of other permutations of config files, etc., but nothing seems to work. Either we get novel exceptions about our config being broken, or with the current setup, none of the classloading stuff seems to take, and we get our NoSuchMethodError exception.

      I have trawled the forums, google, etc. and have seen quite a lot of posts relating to this, or similar issues, but we can't quite seem to hit on the right config.

      Any suggestions gratefully received.







        • 1. Re: JBoss ClassLoader hell. Please help.

          We don't use EAR deployment or EJBs but we did have a number of war files that worked fine under a standalone Tomcat installation. These war's required specific version of some classes.

          To support this I changed a configuration attribute for the whole JBoss Tomcat installation that made it work more like a standalone version. We've not experienced any problems from do thing. I suspect it may not be making best use of the class repository.

          For JBoss 3.2.2:

          In jbossweb-tomcat41.sar/META-INF directory fine the jboss-service.xml attribute.

          Add/change mbean attribute:

          false

          By default it is true.

          Hope this helps.