10 Replies Latest reply on May 28, 2014 11:28 AM by Steve Fisher

    DuplicateServiceException

    Steve Fisher Newbie

      I get the following when I try to deploy a war file:

       

      2014-05-27 17:47:18,370 INFO  [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016005: Starting Services for CDI deployment: icat.ear-4.3.3-SNAPSHOT.war

      2014-05-27 17:47:18,372 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."icat.ear-4.3.3-SNAPSHOT.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."icat.ear-4.3.3-SNAPSHOT.war".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "icat.ear-4.3.3-SNAPSHOT.war"

        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]

        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]

        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]

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

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

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

      Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.naming.context.java.module."icat.ear-4.3.3-SNAPSHOT"."icat.ear-4.3.3-SNAPSHOT".BeanManager is already registered

        at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]

        at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]

        at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]

        at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]

        at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]

        at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]

        at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]

        at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]

        at org.jboss.as.weld.deployment.processors.WeldBeanManagerServiceProcessor.bindBeanManager(WeldBeanManagerServiceProcessor.java:128)

        at org.jboss.as.weld.deployment.processors.WeldBeanManagerServiceProcessor.deploy(WeldBeanManagerServiceProcessor.java:109)

        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]

        ... 5 more

       

      The full log is attached. There is no module of that name already installed so I presume it was registered earlier in the install process. The BeanManager is actually inside icat.core-4.3.3-SNAPSHOT.jar which is within icat.ear-4.3.3-SNAPSHOT.war. Note that it is a war file - please don't be confused the the "ear" in the file name. Any ideas please?

        • 1. Re: DuplicateServiceException
          Eduardo Martins Apprentice

          In your log:

           

          "2014-05-27 17:47:18,274 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-5) JNDI bindings for session bean named BeanManager in deployment unit deployment "icat.ear-4.3.3-SNAPSHOT.war" are as follows:

           

            java:global/icat.ear-4.3.3-SNAPSHOT/BeanManager!org.icatproject.core.manager.BeanManager

            java:app/icat.ear-4.3.3-SNAPSHOT/BeanManager!org.icatproject.core.manager.BeanManager

            java:module/BeanManager!org.icatproject.core.manager.BeanManager

            java:global/icat.ear-4.3.3-SNAPSHOT/BeanManager

            java:app/icat.ear-4.3.3-SNAPSHOT/BeanManager

            java:module/BeanManager"

           

          One of the JNDI names where WildFly binds an EJB is "java:module/" + the EJB name, and since you have an EJB named BeanManager, WildFly binds it to java:module/BeanManager. The problem is that java:module/BeanManager is the JNDI name for CDI's BeanManager in a war deployment, thus the binding conflict.

          • 2. Re: DuplicateServiceException
            Steve Fisher Newbie

            Thanks for the quick response. Unfortunately I don't quite understand. I only have one BeanManager which is the EJB which has been given a variety of JNDI names. It is defined with neither @Local nor @Remote annotations. If I just change the name of BeanManager this will obviously not help so what do you suggest? The war file deploys fine in Glassfish (with just a tweak to the persistence.xml).

            • 3. Re: DuplicateServiceException
              Eduardo Martins Apprentice

              As I said the other java:module/BeanManager is Java EE CDI's BeanManager, if you change your EJB name the conflict will be gone. My guess is that Glassfish binds EJBs to different JNDI names.

              • 4. Re: DuplicateServiceException
                Steve Fisher Newbie

                But "the other" BeanManager is the same one. I have exactly one BeanManager:

                 

                [fisher@smfisher workspace]$ find icat -name BeanManager.java

                icat/core/src/main/java/org/icatproject/core/manager/BeanManager.java

                [fisher@smfisher workspace]$

                 

                so changing its name will only change the error message I think.

                • 5. Re: DuplicateServiceException
                  jaikiran pai Master

                  Steve, what Eduardo is saying is that the "other" BeanManager is the name of an implicit CDI component which too gets bound (implicitly) to JNDI at java;module/BeanManager. So when you introduce a component by the name BeanManager within your application, it then conflicts with that implicit component. One way to deal with it is to rename your BeanManager bean to something else or disable CDI for your deployment. Note that CDI is enabled by default for all deployments as per the spec.

                  • 6. Re: DuplicateServiceException
                    jaikiran pai Master

                    Having said that, I too am curious how GlassFish doesn't run into problem with this. Perhaps you are using an version of GlassFish where CDI isn't enabled by default for all deployments?

                    • 7. Re: DuplicateServiceException
                      Tomaz Cerar Master

                      activation by default can be easily disabled in GlasFish as well as in WildFly

                      see docs about that http://weld.cdi-spec.org/documentation/#4

                      • 8. Re: DuplicateServiceException
                        Steve Fisher Newbie

                        I am pleased to say that Eduardo's solution of renaming the BeanManager does indeed work - and I can move on to the next problem. Looking at the wildfly source I notice that there is a file: clustering/ejb/spi/src/main/java/org/wildfly/clustering/ejb/BeanManager.java which is probably the cause of my problems. I would have though that classloader isolation would mean that this kind of thing can't happen. Is this a bug I should report?

                        • 9. Re: DuplicateServiceException
                          jaikiran pai Master

                          Steve Fisher wrote:

                           

                          Looking at the wildfly source I notice that there is a file: clustering/ejb/spi/src/main/java/org/wildfly/clustering/ejb/BeanManager.java which is probably the cause of my problems. I would have though that classloader isolation would mean that this kind of thing can't happen. Is this a bug I should report?

                          No that's not the cause of the problem. To make a bit more clear, there are certain names to which components get bound in JNDI. CDI BeanManager is one such component which is expected to be bound to java:module/BeanManager key (doesn't matter what the underlying class name is). So when you introduce a EJB in your application, whose simple class name is BeanManager, you are now conflicting with the JNDI key since by default the JNDI key for your beans is going to use the simple class name of the bean implementation class.

                           

                          By the way, instead of renaming your bean implementation class name, you can even do the following:

                           

                          // use the name attribute to override the default name of the bean. Use the correct annotation depending on what your bean is

                          @Stateless (name = "someothername")

                          // @Stateful (name = "someothername")

                          // @Singleton (name="someothername")

                          public class BeanManager {

                           

                          ....

                          }

                          • 10. Re: DuplicateServiceException
                            Steve Fisher Newbie

                            Thanks. Now all is clear.

                             

                            Steve