1 2 Previous Next 20 Replies Latest reply on May 15, 2015 2:55 AM by andreas_w

    Problem with weld during deployment on WildFly 8.2

    andreas_w

      Hi,

       

      we are trying to migrate our application to WildFly 8.2. But we are getting deployment exceptions from Weld a lot of times. As far as I can see the problem is when weld scanning/processing our classes during deployment. Regarding which classes are scanned or processed first we are able to deploy the application or not. We can deploy the same application on WildFly 8.1 but on WildFly 8.2 we are getting most of the times exceptions. But sometimes it is working too. We created a similar post in the WildFly forum (see Problem with weld in WildFly 8.2) but thought as it seems that it is a problem with weld maybe it is better to post it here too.

       

      Our structure of the application is like this

      • application.ear
        • ejb.jar
        • application.war
        • application2.war

       

      if the ejb.jar is scanned/processed before the application.war everything is working. But most of the times it is the other way and the application.war is processed before ejb.jar. In this case we are getting an unsatisfied dependency exception. As application.war is calling ejbs from ejb.jar.

       

      Has anyone an idea what we can do?

       

      thanks in advance

        • 1. Re: Problem with weld during development on WildFly 8.2
          mkouba

          Hi Andreas,

          please post a stacktrace. A simple reproducer/application/test would be helpful as well.

          • 2. Re: Problem with weld during development on WildFly 8.2
            andreas_w

            Hi,

             

            here is the stacktrace

             

            INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016005: Starting Services for CDI deployment: <application>.ear
            INFO  [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900: 2.2.6 (Final)
            INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016008: Starting weld service for deployment <application>.ear
            ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."<application>.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."<application>.ear".WeldStartService: Failed to start service
              at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
              at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_71]
              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_71]
              at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_71]
            Caused by: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.deployment.subunit."<application>.ear"."<application>ejb3.jar".component.<EJB>.VIEW."<package>.<EJB>".REMOTE not found
              at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:668) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
              at org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices.getComponentView(WeldEjbInjectionServices.java:149)
              at org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices.handleServiceLookup(WeldEjbInjectionServices.java:124)
              at org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices.registerEjbInjectionPoint(WeldEjbInjectionServices.java:106)
              at org.jboss.weld.injection.ResourceInjectionFactory$EjbResourceInjectionProcessor.getResourceReferenceFactory(ResourceInjectionFactory.java:243)
              at org.jboss.weld.injection.ResourceInjectionFactory$EjbResourceInjectionProcessor.getResourceReferenceFactory(ResourceInjectionFactory.java:238)
              at org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createFieldResourceInjection(ResourceInjectionFactory.java:207)
              at org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createResourceInjections(ResourceInjectionFactory.java:182)
              at org.jboss.weld.injection.ResourceInjectionFactory.discoverType(ResourceInjectionFactory.java:405)
              at org.jboss.weld.injection.ResourceInjectionFactory.getResourceInjections(ResourceInjectionFactory.java:92)
              at org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:59)
              at org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49)
              at org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:62)
              at org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:46)
              at org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:128)
              at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87)
              at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:91)
              at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:71)
              at org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:264)
              at org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:228)
              at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78)
              at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75)
              at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
              at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
              at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_71]
              ... 3 more
            

             

            But "<EJB>" is always different. Regarding which class is produced first. The strange thing is, that sometimes it is working. But just in vary rare cases.

            • 3. Re: Problem with weld during development on WildFly 8.2
              tremes

              Hi,

              I am not able to reproduce it. Can you please show us your EJB source code (from your ejb.jar) and how do you call it in your application.war? Thank's

              • 4. Re: Re: Problem with weld during development on WildFly 8.2
                andreas_w

                Hi,

                 

                thanks for the answer. I can't show the exact source code, sorry. But the ejb's are looking like this:

                 

                @Stateless
                @Local(SomeClassLocal.class)
                @Remote(SomeClass.class)
                public class SomeClassBean implements SomeClassLocal, SomeClass {
                
                
                     public String getValue(){
                          return "test"
                     }
                
                }
                

                 

                ManagedBean in application.war

                 

                public class MyManagedBean {
                
                     public void getDataFromEjb(){
                          
                          InitialContext ictx = new InitialContext();
                          SomeClass ejbObj = (SomeClass)ictx.lookup(jndiURL);
                          ejbOjb.getValue()
                
                     }
                }
                

                 

                I hope this helps a bit. What I forget to mention. The application was running first on an application server which only supports JavaEE 5. Therefore we haven't used any CDI. But if we tried to disable weld completly some of our masks loaded completly slow. If you need more information just let me know. And thanks again for taking a look at our problem.

                • 5. Re: Re: Re: Problem with weld during development on WildFly 8.2
                  tremes

                  Thank's for more closer information. I guess MyManagedBean won't be the cause of the problem. I guess you have somewhere declared @EJB injection point (to produce the stack trace above). And please what do you mean by:?

                  But "<EJB>" is always different. Regarding which class is produced first.

                  • 6. Re: Re: Problem with weld during development on WildFly 8.2
                    andreas_w

                    oh, yes beside the ManagedBeans we are having some servlets which are using @EJB annotations. They are living either in the application.war or in another war-file which is included in the ear-file.

                     

                    And with "<EJB>" I mean it is always another class where the problem occurs. I guess depending on how the classes are processed. So "<EJB>" is just a placeholder for example for SomeClassBean (which I mentioned in my previous post).

                    • 7. Re: Re: Problem with weld during development on WildFly 8.2
                      tremes

                      Well the reproducer application is really needed. I was experimenting quite a lot with the same deployment structure and I was able to reproduce the same stacktrace only once (and totally randomly) in many attempts. What's the percentage of this failure on your side? I think your deployment is "somehow special" so the reproducer could be helpful.

                      It seems that the resolving of an @EJB injection point sometimes happen before the ejb jar is really processed (ejb service registered). 

                      • 8. Re: Problem with weld during deployment on WildFly 8.2
                        andreas_w

                        Thanks for your answer and your help.

                         

                        It happens a lot of times for us. I would say from 10 deployments it isn't working 8 times. But the strange thing is, that it seems to work when it was deployed once. So if we don't change our app and starting wildfly a few times it seems to work. But after we deploy a new version we are getting the same error.

                         

                        It seems that the resolving of an @EJB injection point sometimes happen before the ejb jar is really processed (ejb service registered). 

                        This makes sense for me, but is there anything we can do against it?

                        • 9. Re: Problem with weld during deployment on WildFly 8.2
                          tremes

                          This makes sense for me, but is there anything we can do against it?

                          I think it's a bug so I am affraid you can't do much. I can file an issue once I am able to reproduce it.

                          • 10. Re: Problem with weld during deployment on WildFly 8.2
                            andreas_w

                            okay, thanks.

                             

                            The strange thing is that with WildFly 8.1 we haven't had this problems. I can try to create an application which I can send to you but this will take some time. Would it help you if I would provide more log-messages? Like setting the log-level for weld to "trace"?

                            • 11. Re: Problem with weld during deployment on WildFly 8.2
                              tremes

                              Well quite a lot of things changed since 8.1 including Weld version (In 8.1 there is 2.1.2.Final). Yes the app would be great. Yes you can try to set the log level to "debug". At least we can take look.:)

                              • 12. Re: Problem with weld during deployment on WildFly 8.2
                                andreas_w

                                okay, the application is a bit difficult, because I can't send you our application. You said you tried it with an own application? Could you give me access to it and I try to modify it in a way that it looks more like our application. Or is this not possible? I will try to set the log-level to debug and post the results here afterwards.

                                 

                                And thanks for your help.

                                • 13. Re: Problem with weld during deployment on WildFly 8.2
                                  tremes

                                  Yes I can. I am not sure whether you are familiar with git but it's available at tremes/core at reproducer · GitHub There is altered EarAccessibilityTest in tests-arquillian folder in my branch called "reproducer". You can execute the test by e.g:

                                   

                                  For remote (running) container

                                  mvn clean verify -Dincontainer=remote -Dtest=EarAccessibilityTest
                                  

                                   

                                  or for standalone container

                                  mvn clean verify -Dincontainer -Dtest=EarAccessibilityTest
                                  

                                   

                                  The test just deploys the given archive structure and that's all. There is no additional test logic. Let me know in case of any problems.

                                  • 14. Re: Problem with weld during deployment on WildFly 8.2
                                    andreas_w

                                    Thank you. I will try this. But I have to install maven first. ;-)

                                     

                                    I will let you know about the results.

                                    1 2 Previous Next