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

[Mark Lowe (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBAS-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Lowe updated JBAS-7883:
----------------------------

        Summary: @Resource mail session injection, injects incorrect mail session  (was: @Resource mail session injection, injects incrrect mail session)
    Description: 
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?



  was:
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?





> @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) 
>    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
>
> 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?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira