@Resource(name="x",lookup="y")

[Dieter Quickfend]

Just wanted to verify this, because the EJB3.1 spec is not clear on this and it's hard to find answers:

@Resource(name="jdbc/SomeDatasource")

equals

@Resource(lookup="MyApp/jdbc/SomeDataSource")

equals

@Resource(lookup="java:MyApp/jdbc/SomeDataSource")

Does not work:

@Resource(name="java:MyApp/jdbc/SomeDataSource")

What can also happen:

@Resource(name="dataSource" lookup="java:MyApp/jdbc/SomeDataSource")
DataSource x;

@Resource(name="dataSource")
DataSource y;

Do I understand the difference between "name" and "lookup" correctly? I've had a lot of trouble grasping this and it's confused me enormously in a few Enthuware questions...

[Jaikiran Pai]

@Resource EE annotation does 2 things:

1) Binds to a (relative) name within the environment naming context (ENC) of the component
2) Looks up from a jndi name

The name attribute that you pass is where it binds to relative to the ENC of the component (which by default is java:comp/env). So if you specify a name = "foo" then it binds the resource to "java:comp/env/foo" so that later at runtime within your component's methods you can do a JNDI lookup with that fully qualified name if you want to.

Now to bind some resource, the @Resource has to (optionally) know from where to fetch the resource from. That's where the lookup attribute plays a role. It tells the container that it has to fetch a resource from the location pointed to by the lookup attribute and bind it to the location pointed to by the (optional) name attribute.

So if you have something like:

@Resource(name="foo", lookup="bar/hello")
private DataSource ds;

Then the container will lookup a resource under "bar/hello" JNDI name and bind it to java:comp/env/foo JNDI name for that component which has this annotation.

[Dieter Quickfend]

But the 'name' attribute also does injection of resources bound in the EJB's environment, right? Like if you specify in ejb-jar.xml an env-entry "myString" for some EJB, the following:

@Resource(name="myString")
String myString;

will inject the resource instead of binding it, and for, let's say a datasource, which is specified as "java:comp/env/jdbc/Muppets" in the JNDI context, the 'name' property is not binding it when it injects this value using:

@Resource(name="jdbc/Muppets")
DataSource ds;



I guess the point of confusion for me is the double task of the 'name' property (i think the 'lookup' on its own is clear enough) and its scope (what can it inject and what can't it inject?)

[Jaikiran Pai]

Dieter Quickfend wrote:But the 'name' attribute also does injection of resources bound in the EJB's environment, right? Like if you specify in ejb-jar.xml an env-entry "myString" for some EJB, the following:

@Resource(name="myString")
String myString;

will inject the resource

No. The name still will be used for "where to bind". There "where to get the resource value from" changes in this case. In this case instead of looking it up from some other jndi name, the value injected is the one from the deployment descriptor.

and for, let's say a datasource, which is specified as "java:comp/env/jdbc/Muppets" in the JNDI context, the 'name' property is not binding it when it injects this value using:

@Resource(name="jdbc/Muppets")
DataSource ds;

I don't understand what you meant there. But even if it's a datasource (or any other resource), the name still represents where to bind in the ENC.

[Dieter Quickfend]

So, if I'm understanding you correctly, specifying "@Resource(name='thisResource') String myString;" behaves exactly the same as "@Resource String myString;" except that the former will also bind the value injected into this component (without knowing where it got it from) as 'thisResource' in the ENC (assuming 'thisResource' doesn't exist)? What happens if 'thisResource' already exists?

[Frits Walraven]

Hi Dieter,

I understand you are struggling as the EJB specs are not always clear, let me try to help you a bit

Dieter Quickfend wrote:So, if I'm understanding you correctly, specifying "@Resource(name='thisResource') String myString;" behaves exactly the same as "@Resource String myString;" except that the former will also bind the value injected into this component (without knowing where it got it from) as 'thisResource' in the ENC (assuming 'thisResource' doesn't exist)? What happens if 'thisResource' already exists?

You should look at it like this:
- every @Resource is equal to a JNDI lookup (so your resource already has got a JNDI name)
- the name parameter refers to the JNDI name (env-entry-name in the ejb-jar.xml)

Just a small example to explain the difference between:

@Resource(name = "initNumber") Integer init;

@Resource Integer anotherInit;

In the first one you will have an ejb-jar.xml of:
<ejb-jar> <enterprise-beans> <session> <ejb-name>EchoBean</ejb-name> <ejb-class>nl.notes.ejb.EchoBean</ejb-class> <session-type>Stateless</session-type> <env-entry> <env-entry-name>initNumber</env-entry-name> <env-entry-type>java.lang.Integer</env-entry-type> <env-entry-value>10</env-entry-value> </env-entry> </session> </enterprise-beans> </ejb-jar>
With the second one you will have an entry declaring the injection target of the resource
<ejb-jar> <enterprise-beans> <session> <ejb-name>EchoBean</ejb-name> <ejb-class>nl.notes.ejb.EchoBean</ejb-class> <session-type>Stateless</session-type> <env-entry> <env-entry-name>init2</env-entry-name> <env-entry-type>java.lang.Integer</env-entry-type> <env-entry-value>13</env-entry-value> <injection-target> <injection-target-class>nl.notes.ejb.EchoBean</injection-target-class> <injection-target-name>anotherInit</injection-target-name> </injection-target> </env-entry> </session> </enterprise-beans> </ejb-jar>
The EJB will look like:

@Stateless
public class EchoBean implements EchoBeanRemote {
   @Resource(name = "initNumber")
   Integer init;
   @Resource
   Integer anotherInit;
   @Resource
   SessionContext context;
   @Override
   public String echo(String phraseToEcho) {
      // do a lookup from the ENC via SessionContext is relative to java:comp/env
      Integer lookupInit = (Integer) context.lookup("initNumber");
      Integer lookupAnotherInit = (Integer) context.lookup("init2");
      return "echo: " + phraseToEcho + init + anotherInit + lookupInit + lookupAnotherInit;
   }
}

What happens if 'thisResource' already exists?

Two <env-entry>s with the same <env-entry-name> won't deploy.

I am not sure whether you are using my notes (ScbcdLinks), but you can find a couple of examples in there in chapter 7.

Regards,
Frits

[Dieter Quickfend]

That clears it up for me. So @Resource(name="") is actually a code-level declaration of an env-entry rather than a JNDI lookup of an env-entry. Thanks a bunch Frits!

And yes, I've been using your notes intensively, after reading the specification, to prepare for the EJB certification (which will be in a few weeks). Thanks a lot, both for this explanation and for your awesome notes! They've been a big help!

[Frits Walraven]

That clears it up for me. So @Resource(name="") is actually a code-level declaration of an env-entry rather than a JNDI lookup of an env-entry.

Well, I wouldn't say that.

Every @Resource is still a JNDI lookup followed by an injection. In the first case the JNDI lookup is done with the name : "java:com/env/initNumber" and that entry exists because it is declared in the ejb-jar.xml (with value 10)

The second case is different, the lookup in initiated by the @Resource, the injection is now done from the deployment descriptor.

There is even a third case possible where you can use both name and lookup.

The third one you will have an ejb-jar.xml of:
<ejb-jar> <enterprise-beans> <session> <ejb-name>EchoBean</ejb-name> <ejb-class>nl.notes.ejb.EchoBean</ejb-class> <session-type>Stateless</session-type> <env-entry> <env-entry-name>init3</env-entry-name> <env-entry-type>java.lang.Integer</env-entry-type> <env-entry-value>13</env-entry-value> </env-entry> </session> </enterprise-beans> </ejb-jar>
and the bean:

@Stateless  
public class EchoBean implements EchoBeanRemote {  
   @Resource(name = "initNumber")  
   Integer init;  
   @Resource  
   Integer anotherInit;  
   // inject the entry at location java:comp/env/init3 and create a shortname entry java:comp/env/i
   @Resource (name="i", lookup="java:comp/env/init3")
   Integer thirdInit;  
   @Resource  
   SessionContext context;  
   @Override  
   public String echo(String phraseToEcho) {  
      // do a lookup from the ENC via SessionContext is relative to java:comp/env  
      Integer lookupInit = (Integer) context.lookup("initNumber");  
      Integer lookupAnotherInit = (Integer) context.lookup("init2");  
      // you will notice that entry java:comp/env/i contains the same as java:comp/env/init3
      Integer lookupInit3 = (Integer) context.lookup("i");
      return "echo: " + phraseToEcho + init + anotherInit + lookupInit + lookupAnotherInit + lookupInit3;  
   }  
} 

The lookup mostly refers to an entry in the global JNDI, but this is just to show you that you can also get it from the components ENC itself.

And yes, I've been using your notes intensively, after reading the specification, to prepare for the EJB certification (which will be in a few weeks). Thanks a lot, both for this explanation and for your awesome notes! They've been a big help!

Thanks

Regards,
Frits

[Dieter Quickfend]

So actually @Resource(name="initNumber") DOES do a JNDI lookup for a specific property in the bean's ENC named initNumber, thus the 'name' property corresponds to a bean-level version of the general-ENC-level 'lookup' property

so:

- when only @Resource without parameters exists, the deployment descriptor MUST specify the injection-target of the environment entries (or the container may infer it automatically (i.e. SessionContext))
- @Resource(lookup="") does a global JNDI lookup
- @Resource(name="someNumber") does a JNDI lookup for a bean-level environment entry called "someNumber"
- @Resource(name="someNumber") can also declare a bean-level environment entry 'binding' if a proper value exists in the deployment descriptor specifying the annotated property as an injection-target
- @Resource(name="someNumber" lookup="java:comp/env/thisIsTheOriginalReference") does a JNDI lookup and binds this value as a bean-level env-entry called 'someNumber'


My confusion is still the double function of the 'name' property I think. I hope I have it right this time.

[Frits Walraven]

Hi Dieter,

I read the specifications again and I now know again how it works (I still find the description in the EJB specs is lacking some important aspects)

Let's go back to the

package nl.notes.ejb;
@Stateless
public class EchoBean implements EchoBeanRemote {
   @Resource
   Integer anotherInit;
   
   public String echo(String phraseToEcho) {
      Integer lookupInit = (Integer) context.lookup("nl.notes.ejb.EchoBean/anotherInit");
      return "echo: " + lookupInit + " : " + anotherInit;
   }
}

The "name" and "type" are not specified in the @Resource annotation, the container will infer the name and type of the resource, so it will look for an entry with (the default) JNDI-name: "nl.notes.ejb.EchoBean/anotherInit" and type "java.lang.Integer" and if it finds the entry in the ejb-jar.xml:
<ejb-jar> <enterprise-beans> <session> <ejb-name>EchoBean</ejb-name> <ejb-class>nl.notes.ejb.EchoBean</ejb-class> <session-type>Stateless</session-type> <env-entry> <env-entry-name>nl.notes.ejb.EchoBean/anotherInit</env-entry-name> <env-entry-type>java.lang.Integer</env-entry-type> <env-entry-value>10</env-entry-value> </env-entry> </session> </enterprise-beans> </ejb-jar> it will inject the value 10 into the field.

So if you go to the next one (which was sort of bugging us)

package nl.notes.ejb;
@Stateless
public class EchoBean implements EchoBeanRemote {
   @Resource (name="initNumber")
   Integer init;
   
   public String echo(String phraseToEcho) {
      Integer lookupInit = (Integer) context.lookup("initNumber");
      return "echo: " + lookupInit + " : " + init;
   }
}

The container now does a lookup without the default name, because there is an explicit name specified. It look for an entry with the JNDI-name "initNumber". This means that if there is an entry with the JNDI-name "initNumber" and type "java.lang.Integer" in the deployment descriptor for this SessionBean (EchoBean):
<ejb-jar> <enterprise-beans> <session> <ejb-name>EchoBean</ejb-name> <ejb-class>nl.notes.ejb.EchoBean</ejb-class> <session-type>Stateless</session-type> <env-entry> <env-entry-name>initNumber</env-entry-name> <env-entry-type>java.lang.Integer</env-entry-type> <env-entry-value>11</env-entry-value> </env-entry> </session> </enterprise-beans> </ejb-jar> it will inject the value 11 into the field "init" of the bean.

And lastly our third case:

package nl.notes.ejb;
@Stateless
public class EchoBean implements EchoBeanRemote {
   @Resource 
   Integer init;
   
   public String echo(String phraseToEcho) {
      // this will throw a javax.naming.NameNotFoundException: No object bound to name java:comp/env/init
      // Integer lookupInit = (Integer) context.lookup("nl.notes.ejb.EchoBean/init");
      return "echo: " + init;
   }
}

The "name" and "type" are not specified in the @Resource annotation, the container will infer the name and type of the resource, so it will look for an entry with (the default) JNDI-name: "nl.notes.ejb.EchoBean/init" and type "java.lang.Integer" and it won't find the entry in the ejb-jar.xml so no injection is done (at first). However there is another environment entry with name "init2" that specifies an injection target of the instance variable "init", this time the injection of value 12 is done from the deployment descriptor into the field "init".
<ejb-jar> <enterprise-beans> <session> <ejb-name>EchoBean</ejb-name> <ejb-class>nl.notes.ejb.EchoBean</ejb-class> <session-type>Stateless</session-type> <env-entry> <env-entry-name>init2</env-entry-name> <env-entry-type>java.lang.Integer</env-entry-type> <env-entry-value>12</env-entry-value> <injection-target> <injection-target-class>nl.notes.ejb.EchoBean</injection-target-class> <injection-target-name>init</injection-target-name> </injection-target> </env-entry> </session> </enterprise-beans> </ejb-jar> (I have not repeated the injections with the "lookup" parameter as those where already clear, right?)

Does this clear up all your doubts?

Regards,
Frits

N.B. I will update my notes with this explanation soon

[Jaikiran Pai]

Frits Walraven wrote:
(I still find the description in the EJB specs is lacking some important aspects)

From what I remember the explanation of @Resource is probably done more in the Java EE spec rather than in EJB spec.

[Frits Walraven]

Jaikiran Pai wrote:
From what I remember the explanation of @Resource is probably done more in the Java EE spec rather than in EJB spec.

Yes, that is true, it is in the JSR-250 "Common Annotations for the Java Platform 1.1" and a bit in JSR-316 "Java Platform, Enterprise Edition 6 Specification 6.0".

The problem in the EJB spec is that it is not all that clear in that respect, whereas the rest of the EJB spec is quite detailed. A few lines of text or a reference to JSR-250 would have helped.

Regards,
Frits

[Dieter Quickfend]

That's pretty clear, Frits, thanks. The only thing I'm still left wondering is that in the third case, where the container finds no env-entry with the name specified (name="init") but finds another ("init2) with the field declared as an injection target, will the annotation "@Resource(name="init") bind the injected value as a bean-level environment entry called "init", as specified in the name?

[Frits Walraven]

No, in that case there will be no entry created in the beans environment and an explicit lookup will fail with a javax.naming.NameNotFoundException.

Regards,
Frits

[Dieter Quickfend]

great, I got it now! Thanks for the help!

[Frits Walraven]

Updated my notes with the topic of this discussion (chapter 7.8.3).

Thanks Dieter for this discussion!