unspecified injection target truly possible?

[Charles O'Leary]

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]

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]

We'll do Frits. Thanks.

[Himai Minh]

To answer your question , on p. 70 of Frit's notes:

package n1.notes.ejb;
public class EchoBean implements EchoBeanRemote{
  
  Integer init;
}

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]

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]

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]

This is an example I came up when I did my EPractice Lab mock exam:

@Stateless
public class InjectionBean {
     private  String s ="1900-01-01"  ;
   private String s1;
	
	@PostConstruct
	public void initialize(){
		s1 = convertString(s);
	}
	 
	public String getString(){
		return this.s1;
	}
	
	private String convertString(String s){
		  s += "YYYY-MM-DD";
		  return s;
	}
}

@WebServlet(name="OtherServlet", urlPatterns="/test.do")
public class OtherServlet extends HttpServlet {
	private static final long serialVersionUID = 1L;
	@EJB InjectionBean injectionBean;
	 
	@Override
	protected void doGet(HttpServletRequest inRequest,
			HttpServletResponse inResponse) throws ServletException, IOException{
		
		 System.out.println("Injected string : "+ injectionBean.getString());
		 
	}	  
}

The ejb-jar.xml:

<ejb-jar version="3.1" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd">
  <display-name>echoejb </display-name> 
  <enterprise-beans>
      <session>
            <ejb-name>InjectionBean</ejb-name>
            <ejb-class>com.ep.InjectionBean</ejb-class>
             <session-type>Stateless</session-type>
            <env-entry>
                 <env-entry-name>com.ep.InjectionBean/s</env-entry-name> 
                 <env-entry-type>java.lang.String</env-entry-type>
                 <env-entry-value>2015-06-06</env-entry-value>
                 <injection-target>
                    <injection-target-class>com.ep.InjectionBean</injection-target-class>
                    <injection-target-name>s</injection-target-name>
                 </injection-target> 
             </env-entry> 
      </session>
    
  </enterprise-beans>
 </ejb-jar>

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]

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]

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.

package nl.notes.ejb;
@Stateless
@LocalBean
public class EchoBean implements EchoBeanRemote {
	
	@Resource
	Integer init = 9;

	@Override
	public String echo(String phraseToEcho) {
		System.out.println("echo:  "+ init + " " + phraseToEcho);
		return phraseToEcho;
	}
}

and the deployment entry:
<?xml version="1.0" encoding="UTF-8"?> <ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:ejb="http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd" version="3.1"> <display-name>echoejb</display-name> <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/init</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>
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)

@WebServlet("/EchoServlet")
public class EchoServlet extends HttpServlet {
 @Override
 protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    ServletOutputStream out = response.getOutputStream();
    out.print("<html><body>");
    InitialContext context;
    try {
             context = new InitialContext();
             EchoBeanRemote d = (EchoBeanRemote) context.lookup("java:global/echoear/echoejb/EchoBean!nl.notes.ejb.EchoBean");
             d.echo("Init value from deployment descriptor");
    } catch (NamingException e) {
		e.printStackTrace();
    }
    out.print("</body></html>");
 }
}

and the web.xml:
<?xml version="1.0" encoding="UTF-8"?> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0"> <display-name>echoweb</display-name> <welcome-file-list> <welcome-file>EchoServlet</welcome-file> </welcome-file-list> </web-app>
gives an output of:

Info: echo: 10 Init value from deployment descriptor

Does this answer your question?

[Charles O'Leary]

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]

Hi Charles,

Good question and nice discussion, you deserve a Cow!

If have updated my notes with this example!

Regards,
Frits

[Charles O'Leary]

Awesome Sauce! Thanks Frits!