JEE Core Concepts - Resources, Naming and Injection

From NovaOrdis Knowledge Base
Jump to navigation Jump to search

Internal

Changing Application Behavior without Changing Code

The possibility to change an application's behavior without changing code is a core concern in JEE. The entire Chapter 5 in the JEE specifications is dedicated to it.

The mechanism than makes this possible is the application component environment, also known as "enterprise naming context" or "ENC".

The application code relies on ENC named entries to refer to configuration values and external resources.

The names of those elements do not change in the code, and those names are mapped to deployment environment specific values and resources during deployment.

The environment specific values can be mapped by declaring them, or referencing them via JNDI lookups, in deployment descriptors. The deployment descriptors act as a layer of indirection between code and the deployment environment. The code does not change, but the deployment descriptors do. The developers have an option to also do that mapping in the code, using "lookup" attributes associated with various annotations, but that results in code less portable between environments.

Application Component Environment

The application component environment is also known as enterprise naming context or ENC.

Environment Entry

Applications use named environment entries to declare a dependency on an external configuration parameter or a resource.

The declarations that express these dependencies can be made in the code, using an annotation like @Resource, or in the component's deployment descriptor.

If annotations are used, the container will inject the appropriate value or resource reference, if it is able to resolve it correctly. An example of such dependency declaration using annotations is: 

@Resource
private int configurationParameterA;

The value can be provided in the deployment descriptor associated with the component that expresses the dependency as follows: 

<web-app ...>
    ...
    <env-entry>
        <env-entry-name>io.example.ServletA/configurationParameterA</env-entry-name>
        <env-entry-type>java.lang.Integer</env-entry-type>
        <env-entry-value>11</env-entry-value>
    </env-entry>
</web-app>

where "io.example.ServletA" is the class that declares the field. More details on @Resource annotation usage are available here: @javax.annotation.Resource.


If deployment descriptor declarations are used, the component will have to look the entry up in the appropriate context using JNDI API calls, and find the value or resource reference there.


Alternatively, the value of the configuration parameter A can be specified in a component deployment descriptor, for example in a web.xml deployment descriptor for a web module, as shown below: 

<web-app ...>
    ...
    <env-entry>
        <env-entry-name>configuration-parameter-B</env-entry-name>
        <env-entry-type>java.lang.Integer</env-entry-type>
        <env-entry-value>22</env-entry-value>
    </env-entry>
</web-app>

and the web components that are deployed as part of that JEE web module can look up the environment entry in JNDI as follows: 

InitialContext c = new InitialContext();

Integer i = (Integer)c.lookup("java:comp/env/configuration-parameter-B");

...




. Examples of such dependencies are:


Simple Environment Entry

Applications use simple environment entries do declare a dependency on an external configuration parameter. Examples of such dependencies are: 

@Resource
private int configurationParameterA;


For more details on @Resource semantics and defaults, see

TODO

Retrieved from "https://kb.novaordis.com/index.php?title=JEE_Core_Concepts_-_Resources,_Naming_and_Injection&oldid=19682"