"wolfc" wrote : Patch #2 is a continuation of the first were I reverted the baseJndiName in JBossEnterpriseBeanMetaData. Subsequently I made it obsolete by introducing a JBossSessionPolicyDecorator which associates a JBossSessionBeanMetaData with a working JNDI binding policy. | As can be seen in the jbmeta42 test this requires an extra step before the meta data is offered to the deployer, but it completely separates out the logic of JNDI name resolving while having it completely obscured to the deployer itself. | | Unit tests are passing 100%, but previously there was a possible issue with profile service storing the wrong data. Is that still the case in this setup? The profile service would only store the non-XmlTransient values, so as long determineResolvedJndiName does not set something like the jndiName, mappedName, its not interfering with the administered view. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152385#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...