DuplicateServiceException

[fisherab]

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?

[emmartins]

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.

[fisherab]

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).

[emmartins]

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.

[fisherab]

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.

[jaikiran]

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.

[jaikiran]

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?

[ctomc]

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

[fisherab]

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?

[jaikiran]

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 {

....

}

[fisherab]

Thanks. Now all is clear.

Steve