7 Replies Latest reply on Nov 9, 2011 6:17 AM by livnats

    Problem in running service

    oourfali

      Hey,

       

      I'm trying to deploy and EAR with a few jars/wars.

      I have a service bean in a jar, which uses another class that is located in the <ear>/lib directory.

       

      When the service starts I get the following error:

      14:06:06,205 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.deployment.subunit."rhevm.ear"."rhevm-bll.jar".component.Backend.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."rhevm.ear"."rhevm-bll.jar".component.Backend.START: Failed to start service

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

              at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)

              at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]

              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]

              at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]

      Caused by: java.lang.IllegalStateException: Failed to construct component instance

              at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:154)

              at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:77)

              at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:125)

              at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)

              at org.jboss.as.ee.component.ComponentStartService.start(ComponentStartService.java:44)

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

              ... 4 more

      Caused by: org.apache.commons.collections.FunctorException: org.nogah.compat.Guid from [Module "org.apache.commons.collections:main" from local module loader @244aeb52 (roots: /home/tlv/oourfali/jboss-as-7.0.1.Final/modules)]

              at org.apache.commons.collections.functors.PrototypeFactory$PrototypeSerializationFactory.create(PrototypeFactory.java:187)

              at org.apache.commons.collections.functors.CloneTransformer.transform(CloneTransformer.java:68)

              at org.nogah.utils.collections.CopyOnAccessMap.clone(CopyOnAccessMap.java:61)

              at org.nogah.utils.collections.CopyOnAccessMap.put(CopyOnAccessMap.java:69)

              at org.nogah.bll.TagsDirector.AddTagToHash(TagsDirector.java:61)

              at org.nogah.bll.TagsDirector.init(TagsDirector.java:55)

              at org.nogah.bll.TagsDirector.getInstance(TagsDirector.java:125)

              at org.nogah.bll.Backend.Initialize(Backend.java:166)

              at org.nogah.bll.Backend.setup(Backend.java:103)

              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_24]

              at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_24]

              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24]

              at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24]

              at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:69)

              at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

              at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

              at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

              at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptor.java:65)

              at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

              at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

              at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

              at org.jboss.as.ee.component.ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptor.java:53)

              at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

              at org.jboss.as.ee.component.ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptor.java:53)

              at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

              at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

              at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

              at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)

              at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

              at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)

              at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:244)

              at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.supports(CMTTxInterceptor.java:448)

              at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:59)

              at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:43)

              at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

              at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)

              at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

              at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)

              at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)

              at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

              at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:152)

              ... 9 more

      Caused by: java.lang.ClassNotFoundException: org.nogah.compat.Guid from [Module "org.apache.commons.collections:main" from local module loader @244aeb52 (roots: jboss-as-7.0.1.Final/modules)]

              at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)

              at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)

              at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)

              at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)

              at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)

              at java.lang.Class.forName0(Native Method) [:1.6.0_24]

              at java.lang.Class.forName(Class.java:247) [:1.6.0_24]

              at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603) [:1.6.0_24]

              at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574) [:1.6.0_24]

              at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) [:1.6.0_24]

              at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) [:1.6.0_24]

              at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_24]

              at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_24]

              at org.apache.commons.collections.functors.PrototypeFactory$PrototypeSerializationFactory.create(PrototypeFactory.java:184)

              ... 49 more

       

      As far as I understand, classes in the <ear>/lib directory can be loaded from jars/wars.

      Also, the jar file containing the class appears in the MANIFEST file of the <ear>/lib jar.

       

      Thank you,

      Oved

        • 1. Re: Problem in running service
          oourfali

          This issue still occurs.

          Does anybody have a clue on how to tackle this issue?

           

          Thank you

          • 2. Re: Problem in running service
            jaikiran

            Which jar/module contains this class org.nogah.compat.Guid and where is that jar located?

            • 3. Re: Problem in running service
              oourfali

              It is a jar located under the <ear>/lib directory.

               

              I found a workaround, although it doesn't really makes sense to me.

              Instead of depending on the apache commons collections module, I added its jar to the lib directory, and removed the module dependency.

              It worked (there are still other unrelated issues, but at least I passed this one).

               

              The reason it didn't work with the module dependency is that for some reason the collections module wasn't able to lead classes from the jar.

              I tried to workaround it also by moving the jar to a new module, but then I made progress only when I added my new module as a new dependency for the collections module (which doesn't make sense at all...).

               

              Any idea why the class loading mechanism behaves that way?

               

              Thank you,

              Oved

              • 4. Re: Problem in running service
                jaikiran

                Oved O wrote:

                 

                 

                The reason it didn't work with the module dependency is that for some reason the collections module wasn't able to lead classes from the jar.

                 

                Yes, that's because the apache collections module is trying to load a class which is not listed as a "module dependency" in the apache collections module. Unless that dependency is added, it can't access those classes in a module environment.

                 

                As to why it works when you move the apache collections jar (and the dependent jar) to .ear/lib is because the apache collections jar will get loaded by the deployments module which has access to all the jars in the .ear/lib.

                • 5. Re: Problem in running service
                  oourfali

                  Thank you for your help.

                   

                  So, what is the best practices for that?

                  To add all the dependencies to the collections module?

                   

                  It seems weird that everytime some component in an ear uses the apache collections then we will have to add a dependency to the collections module.

                   

                  Is the best practice to put it in the <ear>/lib directory as I did?

                   

                  Thank you,

                  Oved

                  • 6. Re: Problem in running service
                    jaikiran

                    Oved O wrote:

                     

                    To add all the dependencies to the collections module?

                     

                    The collections module (or any module for that matter) should be self sufficient (i.e. it should list all of its own dependencies).

                     

                     

                    Caused by: org.apache.commons.collections.FunctorException: org.nogah.compat.Guid from [Module "org.apache.commons.collections:main" from local module loader @244aeb52 (roots: /home/tlv/oourfali/jboss-as-7.0.1.Final/modules)]

                            at org.apache.commons.collections.functors.PrototypeFactory$PrototypeSerializationFactory.create(PrototypeFactory.java:187)

                            at org.apache.commons.collections.functors.CloneTransformer.transform(CloneTransformer.java:68)

                            at org.nogah.utils.collections.CopyOnAccessMap.clone(CopyOnAccessMap.java:61)

                            at org.nogah.utils.collections.CopyOnAccessMap.put(CopyOnAccessMap.java:69)

                            at org.nogah.bll.TagsDirector.AddTagToHash(TagsDirector.java:61)

                            at org.nogah.bll.TagsDirector.init(TagsDirector.java:55)

                            at org.nogah.bll.TagsDirector.getInstance(TagsDirector.java:125)

                            at org.nogah.bll.Backend.Initialize(Backend.java:166)

                            at org.nogah.bll.Backend.setup(Backend.java:103)

                     

                    The important thing to note in that exception stacktrace is that it is an org.apache.collections class (within the apache collections module) which is trying to access some class named org.nogah.compat.Guid, which means that the collections module has a dependency on a module containing that class. So the collections module has to list it as a dependency in its module.xml.

                     

                     

                    Oved O wrote:

                     

                    It seems weird that everytime some component in an ear uses the apache collections then we will have to add a dependency to the collections module.

                     

                    Is the best practice to put it in the <ear>/lib directory as I did?

                     

                     

                    You don't really have to create a module for every other library that your application uses. You can place the jars in the .ear/lib and make them available in the classpath of the application (internally AS7 will create one big dynamic module which will have access to all those libraries, so classes from one jar in ear/lib are accessible from  classes in some other jar in the ear/lib).

                    • 7. Re: Problem in running service
                      livnats

                      After digging a little in the above, a summary that, I hope, can save someone some time:

                       

                      The apache commons comes by default as a module in jboss as7.

                      The problem is that apache commons uses Java serialization mechanism as part of the functionality it offers.

                       

                      Because apache commons is a module in JbossAS7 your local classes are not visible to it and it fails on - "Failed to construct component instance".

                       

                      The solution is indeed to add commons to your local lib (ugly) OR add your lib as a dependency in apache commons module (even uglier)...

                      This was not needed in jboss AS5, as jars from the common/lib dir had visibility to your classes.