"JNDI name is already in use" in Weblogic 12c with EJB3

Gary Kephart picture Gary Kephart · Jul 21, 2015 · Viewed 7.5k times · Source

I have the following code that I'm trying to deploy as an EJB to WebLogic 12c, but I'm getting an error:

"Error deploying the EJB GeopoliticalServiceBean(Application: campaigner-ejb, EJBComponent: campaigner-service.jar), the JNDI name java:global/campaigner-ejb/campaigner-service/GeopoliticalServiceBean!com.dr_dee_sw.campaigner.service.GeopoliticalServiceLocal is already in use. You must set a different JNDI name in the weblogic-ejb-jar.xml deployment descriptor or corresponding annotation for this EJB before it can be deployed."

public interface GeopoliticalService
{
...
}

@Local
public interface GeopoliticalServiceLocal extends GeopoliticalService
{
}

@Remote
public interface GeopoliticalServiceRemote extends GeopoliticalService
{
}

@TransactionManagement(value = TransactionManagementType.CONTAINER)
@TransactionAttribute(value = TransactionAttributeType.REQUIRED)
@Stateless
public class GeopoliticalServiceBean implements GeopoliticalServiceLocal,GeopoliticalServiceRemote
{
...
}

More information: I've reduced the EJB-JAR file, campaigner-service.jar, so that there's only one bean in it, plus the interfaces and exceptions. the EAR file, campaigner-ejb.ear, has only the EJB-JAR in it at the main level. It also has a "lib" directory with supporting libraries, but it only has the DAO and DTO jars in it plus third-party libraries. So, to me, it doesn't seem like a packaging issue.

This is my first app using all annotations, but it still seems fairly straight-forward. What am I missing?

Answer

P_W999 picture P_W999 · May 23, 2017

During the migration from Weblogic 10 to Weblogic 12 we faced the same issue. We could reproduce the issue by deploying the EAR on a fresh server without the datasources configured properly; this would cause a NameNotFoundException during deployment. Every next attempt to deploy the EAR would result in the JDNI name is already in use, even after restarting, undeploying, redeploying.

The only thing that resolved the issue was removing the cache (and most importantly the EJBCompilerCache) and tmp folder of the target server.