JNDI name duplication problem chez WebSphere

Yesterday a colleague and I have faced a subtle problem deploying a suite of enterprise applications on WebSphere Application Server - version 6.1.

The problem manifested itself with a marshalling error when a webapp called a service exposed as an EJB in the same enterprise application: this was very annoying due to two main aspects:

1. there was no duplication, between webapp and EJB module, fot the classes involved in the call
2. the issue seemed to occur randomly: not for all calls (and never for some), not always for the same call (apparently depending to application restart)

After a few hours of stop-and-start-and-read-the-log nightmare, we discovered that at the root of the problem was a JNDI name duplication between EJBs published by two different applications of the suite: these applications are based on the same infrastructural framework, and the framework published some framework services using a fixed JNDI name. This was clearly an error in suite packaging, but... WebSphere did not report in any way this name collision, deployed without errors nor warnings both the applications, and the duplicated JNDI name was associated with an implementation of the service or with the other, depending to starting order of the apps. So:

1. the marshalling problem appeared when the webapp from an EAR called the service published by the other application
2. the issue occurred only for the EJB with the duplicated name, not for the others; and coccurred or did not depending to the starting order

The solution was quite simple: changing the JNDI name of  one of the twins services.
But... why the application server did not give any error when deploying an EJB using an already-in-use JNDI name, as do for example JBoss and BEA Weblogic application servers?

Definitely something to remember!

Quick trick: solving an MDB deploy problem on WebLogic

Quick trick about a problem I've faced deploying a Message Driven Bean on BEA WebLogic: MDB's configuration in ejb-jar.xml contained this snippet:

<message-driven>
    <ejb-name>MyEjb</ejb-name>
    <ejb-class>com.my.domain.MyEjbBean</ejb-class>
    <transaction-type>Container</transaction-type>
    <message-driven-destination>
        <destination-type>javax.jms.Queue</destination-type>
    </message-driven-destination>                       
    <acknowledge-mode>auto_acknowledge</acknowledge-mode>
</message-driven>

This configuration worked well on JBoss 4, but causes causes an exception during deployment phase on BEA WebLogic 10:

Caused By: 

org.hibernate.HibernateException: The chosen transaction strategy requires access to the JTA TransactionManager

 at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:371)

 at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1341)

 at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:867)

 at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:669)

 at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:132)

 at weblogic.deployment.PersistenceUnitInfoImpl.createEntityManagerFactory(PersistenceUnitInfoImpl.java:355)

 at weblogic.deployment.PersistenceUnitInfoImpl.createEntityManagerFactory(PersistenceUnitInfoImpl.java:333)

 at weblogic.deployment.PersistenceUnitInfoImpl.<init>(PersistenceUnitInfoImpl.java:135)

 at weblogic.deployment.AbstractPersistenceUnitRegistry.storeDescriptors(AbstractPersistenceUnitRegistry.java:336)

 at weblogic.deployment.EarPersistenceUnitRegistry.initialize(EarPersistenceUnitRegistry.java:77)

 at weblogic.application.internal.flow.InitJpaFlow.prepare(InitJpaFlow.java:38)

 at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:1223)

 at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:41)

 at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:367)

 at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:58)

 at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:154)

 at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:60)

 at weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:208)

 at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:98)

 at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:217)

 at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:749)

 at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1216)

 at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:250)

 at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:160)

 at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:171)

 at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:13)

 at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:47)

 at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)

 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)

 at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

The problem was the presence of <acknowledge-mode> tag: this has no effect when <transaction-type> is Container (in this case messages ACK coincides with transaction commit). On JBoss the <acknowledge-mode> tag is ignored, but WebLogic validate configuration and raises an Exception when its presence is meaningless.

Removing the tag solved the problem.