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

Friday, 18 September 2015

    [
https://issues.jboss.org/browse/WFLY-5369?page=com.atlassian.jira.plugin....
] 

Jason Greene commented on WFLY-5369:
------------------------------------

Hi Ivn,

If you declare a @Resource without a lookup (or mappedName), then the JNDI name it
resolves is either defined by a deployment descriptor or its set to one of the EE7 defined
default resource. So in this case its “java:comp/DefaultDataSource” per EE 5.1.9. The spec
also requires that duplicate @Resource declarations (specify the same name in the same
namespace) by validated to be identical and error if not (EE 5.2.2 "If all attributes
of each declaration of a shared environment entry are not identical, this must be reported
as a deployment error to the Deployer. "). This is the case since they effectively
specify different names. Now technically with our stock config those names both resolve to
the same underlying resource, so we could be smarter and specially handle that case, but
if the default data source does not match the resource in the class annotation the error
would then still occur. In short, this is not a portable approach to aliasing annotation
declarations, and is precisely what the lookup= attribute is for.

Now as to why it works with Object is a side effect specific to our implementation. Name
binding and field injection are distinct processes, and the use of Object means there is
no provider available to run the binding portion, yet the lookup portion still runs. The
lookup portion uses the names created by the binding portion. This is undefined territory
though so I would not rely on it.

As to why this works on other container vendors, the spec allows a lot of freedom there,
so they may infer the binding in some cases, although being non-standard you may not be
able to rely on the consistency of that behavior. As to why the EE6 tutorial works, the
expectation was likely that the unbound entry would have been defined/configured either on
the server or via a DD.

...
 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)

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006