"wolfc" wrote : | The second example will even fail in 3.1, but I consider it bad practice to have two classes with the same name in 1 module. I think the second example will be handled gracefully in 3.1 as per the specs (Section 4.4.1): anonymous wrote : Each portable session bean global JNDI name has the following syntax : | | java:global[/<app-name>]/<module-name>/<bean-name>#<fully-qualified-interface-name> | | The container registers a separate global JNDI name entry for each local business interface, each remote business interface, and any no-interface view, 2.x local home interface, or 2.x remote home interface. For the the no-interface view, the last portion of the entry name is the fully-qualified bean class name. | The fully-qualified-interface-name will generate a unique JNDI name. "ALRubinger" wrote : | Otherwise we could default the EJB Name to the FQN of the bean impl class, but I think that'll cause more problems (migration) that it'll solve. | I agree - changing the default EJB name at this point would not be of much help for this not so common scenario. "ALRubinger" wrote : | So the workaround is to set it explicitly. | Right, but the current behaviour just silently ignores the 2nd EJB and does not bind it. So if we have the information that we have already bound bean1 to the same name then maybe we could log a WARN message to highlight this issue so that the user opts for the workaround. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183564#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...