[jboss-jira] [JBoss JIRA] (WFLY-5369) Wildfly doesn't handle @Resource name attribute for DataSource type

[Ivn Lahav (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110587#comment-13110587 ] 

Ivn Lahav commented on WFLY-5369:
---------------------------------

Hi Jason,

The name attribute of the @Resource does represent the destination of the binding to create but only when when combined with the actual instruction (lookup or mappedName) to create such binding. When used without lookup or mappedName it represents the source in ENC to inject from.

When using lookup instead of name for injection, it will actually create additional binding, with a default name derived from the class and field names. In your example above, it will inject the correct value but will create a binding as can be verified by:

{code}
System.out.println(InitialContext.doLookup("java:comp/env/pkg.Servlet2/ds"));
{code}

I verified using name for injection on Weblogic and on TomEE and it works properly. In fact, it also works in Wildfly as well, as long as the type is not DataSource. 
I tried the original example from above with JMS Queue and also with a simple Integer, and it works without any issue. Also even with DataSource, by changing the type of the field from DataSource to Object it starts working. So there is some bug with DataSource injection.

By the way, as one of the examples that shows resource injection by name, see
  https://docs.oracle.com/javaee/6/tutorial/doc/bncjk.html


> Wildfly doesn't handle @Resource name attribute for DataSource type
> -------------------------------------------------------------------
>
>                 Key: WFLY-5369
>                 URL: https://issues.jboss.org/browse/WFLY-5369
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 9.0.1.Final
>            Reporter: Ivn Lahav
>            Assignee: Jason Greene
>             Fix For: No Release
>
>
> When using {{@Resource}} with {{name}} attribute to inject an object from environment naming context (ENC) into a servlet or EJB, Wildfly is producing an error.
> Here is an example from injecting into Servlet (the same is with injecting into EJBs).
> First the part that does work:
> {code}
> @WebServlet(loadOnStartup=1)
> @Resource(name="db1", lookup="java:jboss/datasources/ExampleDS", type=DataSource.class)
> public class Servlet1 extends HttpServlet {
>         @PostConstruct
> 	public void init0() throws Exception {
> 		System.out.println("___________db1: " + InitialContext.doLookup("java:comp/env/db1"));
> 	}
> }
> {code}
> So we can see that the ENC entry {{db1}} is properly defined and can be looked up.
> Now we  add a field to the above class and use {{@Resource}} injection:
> {code}
> @Resource(name='db1')
> DataSource ds;
> {code}
> we get the this error:
> {code}
> Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:module/env/db1 source: lookup (java:jboss/datasources/ExampleDS)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:221)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:183)
> 	at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:187)
> 	at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:144)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> 	... 5 more
> {code}
> Interestingly, if I change the data type of a field from {{DataSource}} to {{Object}}, things start working.
> This is a very basic functionality of Java EE and we are using it extensively to produce vendor independent deployment units that directly reference only logical ENC entries and not physical vendor specific JNDI names. Then during deployment the administrator would customize the mapping to match the application server and a specific environment.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)