Details
-
Type:
Bug
-
Status: Open (View Workflow)
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: EJB 3.1
-
Fix Version/s: None
-
Component/s: ejb3_1
-
Labels:None
Description
Both try to bind to the same JNDI name causing the second WAR to fail deployment:
13:49:05,276 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=vfs:///C:/Java/AS/jboss-6.0.0-SNAPSHOT/server/default/deploy/LTK.war$Kirjautumistoiminnot state=Create: javax.naming.NameAlreadyBoundException: no-interface
at org.jnp.server.NamingServer.bind(NamingServer.java:209) [:5.0.5.Final]
at org.jnp.server.NamingServer.bind(NamingServer.java:167) [:5.0.5.Final]
at org.jnp.interfaces.NamingContext.bind(NamingContext.java:652) [:5.0.5.Final]
at org.jnp.interfaces.NamingContext.bind(NamingContext.java:613) [:5.0.5.Final]
at org.jboss.util.naming.Util.bind(Util.java:105) [jboss-common-core.jar:2.2.17.GA]
at org.jboss.util.naming.Util.bind(Util.java:91) [jboss-common-core.jar:2.2.17.GA]
at org.jboss.ejb3.nointerface.impl.jndi.SessionAwareNoInterfaceViewJNDIBinder.bindNoInterfaceView(SessionAwareNoInterfaceViewJNDIBinder.java:118) [:]
at org.jboss.ejb3.nointerface.impl.jndi.NoInterfaceViewJNDIBinderFacade.onStart(NoInterfaceViewJNDIBinderFacade.java:127) [:]
at sun.reflect.GeneratedMethodAccessor336.invoke(Unknown Source) [:1.6.0_20]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.0.Alpha9]
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.0.Alpha9]
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:257) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:202) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:182) [:2.2.0.Alpha8]
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58) [:2.2.0.Alpha8]
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [:2.2.0.Alpha8]
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.Alpha8]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.Alpha10]
at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.Alpha8]
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.Alpha8]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0-SNAPSHOT]
at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:130) [:0.1.0.Alpha1]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.1.0.Alpha1]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:59) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:94) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.1.0.Alpha1]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.1.0.Alpha1]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.1.0.Alpha1]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.1.0.Alpha1]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_20]
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_20]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_20]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_20]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) [:1.6.0_20]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) [:1.6.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_20]
Gliffy Diagrams
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
Overriding the "name" of the bean in either one of the app or both the apps can get you past this issue. For example:
@Stateful(name="CommonBeanInApp1")
public class CommonNoInterfaceViewBean
@Stateful(name="CommonBeanInApp2")
public class CommonNoInterfaceViewBean
jaikiran pai
added a comment - Overriding the "name" of the bean in either one of the app or both the apps can get you past this issue. For example:
@Stateful(name="CommonBeanInApp1")
public class CommonNoInterfaceViewBean
{
...
}
@Stateful(name="CommonBeanInApp2")
public class CommonNoInterfaceViewBean
{
..
}
This is somewhat manageble if you have separate applications and you can choose your name but it gets really nasty when you have two applications, Foo and TestFoo on the same AS.
You'll have to start two servers then, one for test and one for deployment to work around it?
Nicklas Karlsson
added a comment - This is somewhat manageble if you have separate applications and you can choose your name but it gets really nasty when you have two applications, Foo and TestFoo on the same AS.
You'll have to start two servers then, one for test and one for deployment to work around it? Adding an IRC conversation that we had the other day on #jboss-dev. We might be able to "fix" this for JBoss AS 6.1.0:
(01:47:24 IST) nickarls: over at #seam-dev the persistence module had run into a variation of https://issues.jboss.org/browse/EJBTHREE-2197 any updates on that?
(01:47:26 IST) jbossbot: jira EJBTHREE-2197 Two WARs containing no-local-view EJBs with same name fails to deploy [Open, Major, jaikiran pai] https://issues.jboss.org/browse/EJBTHREE-2197
(01:47:55 IST) ***Jaikiran checks
(01:48:08 IST) nickarls: I think they went on re-writing the transaction-synch EJB to use the transaction manager directly or something
(01:49:04 IST) Jaikiran: nickarls: unfortunately, "fixing" it in AS6 is almost next to impossible. i.e. without breaking the backward compatibility
(01:49:09 IST) Jaikiran: for ex:
(01:49:22 IST) Jaikiran: assume you have a A.war and B.war with MyBean in both
(01:49:31 IST) Jaikiran: currently it binds to MyBean/no-interface
(01:49:47 IST) Jaikiran: and that's kind of the contract in AS6. i.e. there are various applications using that jndi name out there
(01:50:18 IST) Jaikiran: to fix this EJBTHREE-2197 issue, we would have to change the jndi name to A/MyBean/no-interface and B/MyBean/no-interface
(01:50:18 IST) jbossbot: jira EJBTHREE-2197 Two WARs containing no-local-view EJBs with same name fails to deploy [Open, Major, jaikiran pai] https://issues.jboss.org/browse/EJBTHREE-2197
(01:50:32 IST) Jaikiran: which then would break the applications which were relying on the older name.
(01:50:35 IST) nickarls: has this always been the case in the 4 and 5 series ,too?
(01:50:48 IST) Jaikiran: AS4 and AS5 did not allow deploying beans in .war
(01:50:49 IST) nickarls: (for normal interface EJBs)
(01:50:54 IST) Jaikiran: they allowed it in .ear
(01:51:04 IST) Jaikiran: and in that case it used to prefix the .ear name to the jndi name
(01:51:16 IST) Jaikiran: we just missed doing the same for .war when we first introduced this in AS6
(01:51:49 IST) Jaikiran: thinking back about this, we shouldn't really have exposed this JBoss specific jndi name. we could just have followed the EJB3.1 spec and asked the users to use that name
(01:51:57 IST) Jaikiran: that way we could have avoided this conflict
(01:52:38 IST) nickarls: yeah, post-portem thinking is always easty 
(01:52:39 IST) Jaikiran: thinking about this a bit more i think i might have a way out
(01:52:57 IST) Jaikiran: a config option which would allow users to switch between these 2 jndi name formats in 6.1.0
(01:53:11 IST) Jaikiran: that way, people wanting this existing scheme won't be affected
(01:53:28 IST) Jaikiran: and people running into this conflicts can switch to the new scheme
(01:53:39 IST) Jaikiran: let me just add this note to the JIRA and start looking at it.
jaikiran pai
added a comment - - edited Adding an IRC conversation that we had the other day on #jboss-dev. We might be able to "fix" this for JBoss AS 6.1.0:
(01:47:24 IST) nickarls: over at #seam-dev the persistence module had run into a variation of https://issues.jboss.org/browse/EJBTHREE-2197 any updates on that?
(01:47:26 IST) jbossbot: jira EJBTHREE-2197 Two WARs containing no-local-view EJBs with same name fails to deploy [Open, Major, jaikiran pai] https://issues.jboss.org/browse/EJBTHREE-2197
(01:47:55 IST) ***Jaikiran checks
(01:48:08 IST) nickarls: I think they went on re-writing the transaction-synch EJB to use the transaction manager directly or something
(01:49:04 IST) Jaikiran: nickarls: unfortunately, "fixing" it in AS6 is almost next to impossible. i.e. without breaking the backward compatibility
(01:49:09 IST) Jaikiran: for ex:
(01:49:22 IST) Jaikiran: assume you have a A.war and B.war with MyBean in both
(01:49:31 IST) Jaikiran: currently it binds to MyBean/no-interface
(01:49:47 IST) Jaikiran: and that's kind of the contract in AS6. i.e. there are various applications using that jndi name out there
(01:50:18 IST) Jaikiran: to fix this EJBTHREE-2197 issue, we would have to change the jndi name to A/MyBean/no-interface and B/MyBean/no-interface
(01:50:18 IST) jbossbot: jira EJBTHREE-2197 Two WARs containing no-local-view EJBs with same name fails to deploy [Open, Major, jaikiran pai] https://issues.jboss.org/browse/EJBTHREE-2197
(01:50:32 IST) Jaikiran: which then would break the applications which were relying on the older name.
(01:50:35 IST) nickarls: has this always been the case in the 4 and 5 series ,too?
(01:50:48 IST) Jaikiran: AS4 and AS5 did not allow deploying beans in .war
(01:50:49 IST) nickarls: (for normal interface EJBs)
(01:50:54 IST) Jaikiran: they allowed it in .ear
(01:51:04 IST) Jaikiran: and in that case it used to prefix the .ear name to the jndi name
(01:51:16 IST) Jaikiran: we just missed doing the same for .war when we first introduced this in AS6
(01:51:49 IST) Jaikiran: thinking back about this, we shouldn't really have exposed this JBoss specific jndi name. we could just have followed the EJB3.1 spec and asked the users to use that name
(01:51:57 IST) Jaikiran: that way we could have avoided this conflict
(01:52:38 IST) nickarls: yeah, post-portem thinking is always easty
(01:52:39 IST) Jaikiran: thinking about this a bit more i think i might have a way out
(01:52:57 IST) Jaikiran: a config option which would allow users to switch between these 2 jndi name formats in 6.1.0
(01:53:11 IST) Jaikiran: that way, people wanting this existing scheme won't be affected
(01:53:28 IST) Jaikiran: and people running into this conflicts can switch to the new scheme
(01:53:39 IST) Jaikiran: let me just add this note to the JIRA and start looking at it.
Does anyone know if the config option mentioned was ever added to AS 6.1?
John Doyle
added a comment - Does anyone know if the config option mentioned was ever added to AS 6.1? No it wasn't added.
jaikiran pai
added a comment - No it wasn't added. 
So you have .war with multiple EJBs with the same name? I'll have to check what the spec says about this.