EJBTHREE-2047 introduced the ContainerNameMetaDataProcessor which is responsible for setting the container name in the JBossEnterpriseBeanMetaData. This processor generates the container name based on the deployment unit name and its top level unit name. Currently it checks whether the toplevel unit is an .ear file:
In case of EJBs packaged in a .jar which resides in a .sar, this check returns false (as expected) and hence the container name doesn't take into account the top level deployment. This leads to a container name which is different from what the JavaEEComponentHelper.createObjectName() method generates. Note that in it's current state, for things to work properly, these two generated names (from different sources) should match.
The ContainerNameMetaDataProcessor should hence be changed to take into account any type of top level unit instead of just .ear files.
EJBTHREE-2047 introduced the ContainerNameMetaDataProcessor which is responsible for setting the container name in the JBossEnterpriseBeanMetaData. This processor generates the container name based on the deployment unit name and its top level unit name. Currently it checks whether the toplevel unit is an .ear file:
private boolean isEar(DeploymentUnit unit) { return unit.getSimpleName().endsWith(".ear") || unit.getAttachment(JBossAppMetaData.class) != null; }
In case of EJBs packaged in a .jar which resides in a .sar, this check returns false (as expected) and hence the container name doesn't take into account the top level deployment. This leads to a container name which is different from what the JavaEEComponentHelper.createObjectName() method generates. Note that in it's current state, for things to work properly, these two generated names (from different sources) should match.
The ContainerNameMetaDataProcessor should hence be changed to take into account any type of top level unit instead of just .ear files.