[jboss-jira] [JBoss JIRA] Updated: (JBAS-7883) @Resource mail session injection, injects incorrect mail session

@Resource mail session injection, injects incorrect mail session ---------------------------------------------------------------- Key: JBAS-7883 URL: https://jira.jboss.org/jira/browse/JBAS-7883 Project: JBoss Application Server Issue Type: Bug Security Level: Public(Everyone can see) Components: Other Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA Environment: Linux 64 bit , sun JDK 1.6.0.14 Reporter: Mark Lowe Attachments: JBAS-7883.patch, jboss-testcase-JBAS-7883.tar.gz Please forgive me if I've posted this to the incorrect component or failed to find an existing bug, I did look. I'm porting our applications from Jboss 4.2.3 and found the following problem injecting mail sessions in EJBs and Servlet components. I have several mails sessions configured. For example <mbean code="org.jboss.mail.MailService" name="jboss:service=MyMailServer1"> <attribute name="JNDIName">foo/MyMailServer1</attribute> <attribute name="User">myuser</attribute> <attribute name="Password">myuserpw</attribute> <attribute name="Configuration"> <configuration> .. </configuration> </attribute> <depends>jboss:service=Naming</depends> </mbean> The jndi tree is created and all is present and correct. @Resource(name="MyMailServer1",mappedName="foo/MyMailServer1") private Session session; Returns the default mail session (java:/Mail). When I removed the java:/Mail session jboss find the last session from the configuration and arbitrarily injects it. I also tested this placing another configuration after the java:/Mail config, and the result was that the session configured below (i.e. last) was referenced. In short to recreate the bug. Create 2 additional mail sessions in a *-service.xml file. Deploy a servlet, ejb or other component that supports @Resource. Attempt to inject one of the custom sessions (not java:/Mail using @Resource(mappedName="[jndi name]". I also attempted to force the issue using a resource-ref in jboss.xml matching the resource-ref-name with the @Resource(name=".") and using the jndi-name (in case the usage of mappedname as been changed since 4.2.3. ) With no result. Assuming this is a real bug, workarounds?