Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

unspecified injection target truly possible?

 
Charles O'Leary
Ranch Hand
Posts: 54
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ranchers,


The following rules apply to how a deployment descriptor entry may override a Resource annotation:
• The relevant deployment descriptor entry is located based on the JNDI name used with the
annotation (either defaulted or provided explicitly).
...
• The injection target, if specified, must name exactly the annotated field or property method.


With an unspecified injection target, how is it possible for a deployment descriptor entry to override a Resource annotation? Does the required JNDI name (whether defaulted or explicit) in and of itself, not always "specify" the injection target?
 
Frits Walraven
Creator of Enthuware JWS+ V6
Saloon Keeper
Pie
Posts: 2536
113
Android Chrome Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Charles,

This part of the specs is indeed a bit confusing (to say the least...).

Did you read the chapter (7.8) of my notes? That might help.
 
Charles O'Leary
Ranch Hand
Posts: 54
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We'll do Frits. Thanks.
 
Himai Minh
Ranch Hand
Posts: 1361
7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To answer your question , on p. 70 of Frit's notes:


The DD can inject a value to this init :

<env-entry>
...
<env-entry-value>10</env-entry-value>
<injection-target>
<injection-target-class>n1.notes.ejb.EchoBean</injection-target-class>
<injection-target-name>init</injection-target-name>
</injection-target>
</env-entry>




Make sure injection-target-name init is the same as the one in the EchoBean.
The JNDI name of init is n1.notes.ejb.EchoBean/init

 
Charles O'Leary
Ranch Hand
Posts: 54
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Himai,
I may be missing what you are trying to convey, but the question was about overriding when there is an unspecified injection target. The spec says that this is possible in the second bullet that I initially provided. Your provided example specifies an injection target. Additionally, it does not define an @Resource annotation ... so I suspect that it is not overriding. Please assist me in understanding your example. (Please note that I haven't read Frits text yet/recently.)
 
Charles O'Leary
Ranch Hand
Posts: 54
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's my current take in an attempt to answer my own question ... please let me know if I'm off base:

Restrictions on the overriding of environment entry values depend on the type of environment entry.



Resource Manager Connection Factory References
...
The res-type element contains the Java type of the resource manager connection factory that the enterprise
bean code expects. The res-type element is optional if an injection target is specified for the
resource; in this case, the res-type defaults to the type of the injection target.

With this specific environment entry, I take it that when res-type element and/or it's annotation equivalent is specified, then the deployment descriptor injection target can go unspecified so long as there is a (valid) deployment descriptor with a deployment descriptor entry located based on the JNDI name used in the annotation? Correct?
 
Himai Minh
Ranch Hand
Posts: 1361
7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is an example I came up when I did my EPractice Lab mock exam:



The ejb-jar.xml:


The output is 2015-06-06 instead of 1900-01-01. The deployment descriptor overrides the value of the variable in the bean.
Is this example related to what you ask?
 
Charles O'Leary
Ranch Hand
Posts: 54
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The example provided does not override a Resource annotation either (since it [also] isn't using a Resource annotation)... I don't think that the relevant deployment descriptor entry could be located based upon a non-existent Resource annotation in order to even attempt an override. (JSR220, 16.2.3, 1Z0-860)

Let's assume the example did properly override a Resource annotation with your injection target (element and subelements) specifications. If it successfully did the override, once you were to remove the injection target and/or have an an "unspecified" injection target, would you always arrive at the same result? In other words, if you did/would have, would it comply with the specs and/or is it applicable across all ejb containers?
 
Frits Walraven
Creator of Enthuware JWS+ V6
Saloon Keeper
Pie
Posts: 2536
113
Android Chrome Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Charles,

Let me try to answer your question. Yes, you can override the @Resource annotation with a deployment descriptor entry (without an injection-target). And yes, it is based on the JNDI name.


and the deployment entry:

When the "name" and "type" are not specified in the @Resource annotation, the container will infer the name and type from the resource, so it will look for an entry with (the default) JNDI-name: "nl.notes.ejb.EchoBean/init" and type "java.lang.Integer". If it finds that entry in the ejb-jar.xml it will inject the value from there into the EJB (value 10 in this case).

To make the example work I have created a simple Servlet (located in echoweb and together with echoejb inside echoear)

and the web.xml:

gives an output of:
Info: echo: 10 Init value from deployment descriptor


Does this answer your question?
 
Charles O'Leary
Ranch Hand
Posts: 54
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Frits, Fully.

Thanks Frits and Himai!

As far as I could tell, for (my and others) later reference, relevant text supporting Frits' example is as follows:



Restrictions on the overriding of environment entry values depend on the type of environment entry.
...

It is often convenient to declare a field as an injection target, but to specify a default value in the code, as
illustrated in the following example.
// The maximum number of tax exemptions, configured by the Deployer.
@Resource int maxExemptions = 4; // defaults to 4

To support this case, the container must only inject a value for the environment entry if the application
assembler or deployer has specified a value to override the default value. The env-entry-value
element in the deployment descriptor is optional when an injection target is specified. If the element is
not specified, no value will be injected. In addition, if the element is not specified, the named resource is
not initialized in the naming context, and explicit lookups of the named resource will fail.


My interpretation is that since the (sometimes optional) injection target is unspecified, the (also sometimes optional) env-entry-value element in the deployment descriptor is/becomes required to provide for a successful override.


 
Frits Walraven
Creator of Enthuware JWS+ V6
Saloon Keeper
Pie
Posts: 2536
113
Android Chrome Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Charles,

Good question and nice discussion, you deserve a Cow!

If have updated my notes with this example!

Regards,
Frits
 
Charles O'Leary
Ranch Hand
Posts: 54
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Awesome Sauce! Thanks Frits!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic