1 Reply Latest reply on Apr 6, 2016 6:20 AM by Stian Lund

    The concept of "Shared Libraries" in JBoss 6

    Stian Lund Expert

      Hey,

      we are running a big WAS installation, but are migrating a few apps to JBoss 6.0 on Linux.

       

      One thing our apps use extensively is the concept of WAS "Shared libraries" where you can add file system paths to the classloader, and map this to either the application or individual modules. This allows for instance properties files like log4j.properties be separate from the deployment and can be edited runtime if need be.

       

      So my question is; is there a way to accomplish something similar in JBoss, so that you can avoid placing config-files in server/lib or in WEB-INF/classes etc (which is frankly not very elegant)?

        • 1. Re: The concept of "Shared Libraries" in JBoss 6
          Manoj Madne Newbie

          Hi,

          I am also looking to get the answers for the above query. Can anybody please share the view on this? I have just drafted the problem that we are facing with regars to migrating to JBOSS 7.

           

          So basically we want to deploy our application on JBoss 7 which make use of plenty of third party jars from vendor partner related to their core business functionalists. Now this application perfectly works fine on WAS and even on Tomcat but when I try to deploy it on JBoss I am getting the below exception, which I believe is related to the conflict it gets due to as it can find the same set of similar jars with may be different versions on JBoss and so getting the below exception.

           

          I had faced the similar issue on WAS for my previous project and we could resolved it by creating the shared library on WAS which allowed us to configure/override the class loader configuration on WAS which made it very easy to create and associate the shared library with the application and solved the issue.

           

          Exception:

          16:30:23,915 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."bfgw-web.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."bfgw-web.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment "bfgw-web.war"

            at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]

            at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]

            at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]

            at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [rt.jar:1.6.0_29]

            at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.6.0_29]

            at java.lang.Thread.run(Unknown Source) [rt.jar:1.6.0_29]

          Caused by: java.lang.NoClassDefFoundError: com/infragistics/faces/grid/component/RowItem

            at java.lang.Class.getDeclaredConstructors0(Native Method) [rt.jar:1.6.0_29]

            at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) [rt.jar:1.6.0_29]

            at java.lang.Class.getConstructor0(Unknown Source) [rt.jar:1.6.0_29]

            at java.lang.Class.getConstructor(Unknown Source) [rt.jar:1.6.0_29]

            at org.jboss.as.jsf.deployment.JSFManagedBeanProcessor.deploy(JSFManagedBeanProcessor.java:103)

            at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]

            ... 5 more

          Caused by: java.lang.ClassNotFoundException: com.infragistics.faces.grid.component.RowItem from [Module "deployment.bfgw-web.war:main" from Service Module Loader]

            at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final-redhat-2]

            at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final-redhat-2]

            at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final-redhat-2]

            at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.3.0.Final-redhat-2]

            at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final-redhat-2]

            at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final-redhat-2]

            ... 11 more

           

          So actually I want to know if I can do the similar thing in JBoss 7 or is there any alternative where I can configure and allow JBoss to look for dependent jars only within war and just ignore the jars from server.

          Any help or suggestions are highly appreciated as it has been pending since long and lot of efforts have been put by the team but no luck.

          • 2. Re: The concept of "Shared Libraries" in JBoss 6
            Stian Lund Expert

            Holy Thread Necromancy Batman!

             

            Thanks for digging it up though, I never got a reply here and it's not really well documented we had to improvise based on what was available. Also this was for JBoss6, we've since moved on to 7.1 and EAP6.

             

            Here's a couple of suggestions:

             

            - Set env.variable JBOSS_MODULEPATH and add the directory, make sure the defaults (JBOSS_HOME/modules) are still there though.

            JBOSS_MODULEPATH="$JBOSS_HOME/modules:$JBOSS_MODULES_HOME:$APPS_HOME/$APP_NAME/app-config"

             

            - Make a symlink from /opt/jboss/modules named for instance 'config' to where your libraries are, then make your apps refer to this in the Manifest. (hard to maintain but works...)

            Dependencies: config.xyz

             

            Also see this: https://developer.jboss.org/thread/170826

             

            hth,

            Stian