ContainerNameMetaDataProcessor generates incorrect container name for EJB packaged in a jar which resides in a .sar ------------------------------------------------------------------------------------------------------------------- Key: EJBTHREE-2098 URL: https://jira.jboss.org/browse/EJBTHREE-2098 Project: EJB 3.0 Issue Type: Bug Components: deployers Affects Versions: bom-eap5-0.1.0, EJB3_1 1.0.7 Reporter: jaikiran pai Assignee: jaikiran pai 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira