1 Reply Latest reply on Feb 27, 2013 3:19 PM by lafr

    How to solve jboss7 module dependency on ear/lib's jar

    pramanish

      Hi,

       

      I am using seam3,JSF2, Richfaces 4 and Jboss7 for my application. My application is bundled in ear containing ejb and war module.

      I have code in ejb which has dependency on JSF,richfaces and seam-faces. I went through https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7 and added following maven dependency so that JSF, Richfaces and seam-faces dependencies will be added explicitly through it.

       

      <manifestEntries>

                                  <Dependencies>javax.faces.api export,org.richfaces export</Dependencies>

      </manifestEntries>

       

      In my org.richfaces module I am also putting seam-faces jar so using single module for the different dependencies. Now the problem is that seam-faces is internally having dependency on solder api and there is no module in jboss7 for solder so Its its not finding solder dependency and throwing :

       

      19:26:48,149 WARN  [org.jboss.weld.deployer] (MSC service thread 1-6) JBAS016006: Could not load portable extension class org.jboss.seam.faces.component.ValidatorConverterScopeOverrideExtension: java.lang.RuntimeException: Error getting reflective information for class org.jboss.seam.faces.component.ValidatorConverterScopeOverrideExtension with ClassLoader ModuleClassLoader for Module "org.richfaces:main" from local module loader @7b888da5 (roots: D:\manish\jboss-as-7.1.1.Final\modules)

          at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:70)

          at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadExtension(WeldPortableExtensionProcessor.java:116) [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final]

          at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:100) [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final]

          at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:86) [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final]

          at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113)

          at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)

          at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)

          at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0]

          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0]

          at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]

      Caused by: java.lang.NoClassDefFoundError: Lorg/jboss/solder/logging/internal/Logger;

          at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.7.0]

          at java.lang.Class.privateGetDeclaredFields(Class.java:2308) [rt.jar:1.7.0]

          at java.lang.Class.getDeclaredFields(Class.java:1760) [rt.jar:1.7.0]

          at org.jboss.as.server.deployment.reflect.ClassReflectionIndex.<init>(ClassReflectionIndex.java:57)

          at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:66)

       

       

      Now, the problem is if I create solder module in jboss7 then it may ask for other api used in solder and I might end up by creating too many modules so is there any simple way to get this working.

       

      Note : I am putting all jars insider Ear/ not in Ear/lib  and my ejb and war modules are using manifest.mf and classpath to resolve dependency from ear.

       

      Thanks in advance.

      Manish

        • 1. Re: How to solve jboss7 module dependency on ear/lib's jar
          lafr

          In my eyes, creating modules is only useful, when you can make reuse of it, having multiple deployments using the same modules.

          If there is only one or very few deployment(s), it might be better and more convenient to put everything into the deployment unit itself (ear or war). In case of ear into ear/lib.

          So you can easily deploy an updated ear with new major or minor versions of the libs used.

           

          But in anyway, you'll have to put all needed jars either into the lib folder of the ear or into one or multiple modules.

          Creating a module for each jar is definitely not the most convenient way.