JEE Core Concepts - Resources, Naming and Injection: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(14 intermediate revisions by the same user not shown)
Line 9: Line 9:
The mechanism than makes this possible is the [[#Application_Component_Environment|application component environment]], also known as "enterprise naming context" or "ENC".  
The mechanism than makes this possible is the [[#Application_Component_Environment|application component environment]], also known as "enterprise naming context" or "ENC".  


The application code relies on [[#Environment_Entry|ENC named entries]] to refer to configuration values and external resources.  
The application code relies on [[#Environment_Entry|ENC named entries]] to refer to configuration values and external resources. Typically, application behavior can be changed externally by providing different ''parameter values''  or connecting the application with different ''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 names of those elements do not change in the code, and those names are mapped to deployment environment specific values and resources during deployment.
Line 18: Line 18:


The application component environment is also known as ''enterprise naming context'' or ENC.
The application component environment is also known as ''enterprise naming context'' or ENC.
[[Image:Application_Component_Environment.png]]


=Environment Entry=
=Environment Entry=
Line 25: Line 27:
The declarations that express these dependencies can be made in the code, using an annotation like @Resource, or in the component's deployment descriptor.  
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.  
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:
 
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.
 
An example of such dependency declaration using annotations is:


<pre>
<pre>
Line 36: Line 34:
</pre>
</pre>


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


<pre>
<pre>
<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>
</pre>
</pre>


Alternatively, the value of the configuration parameter A can be specified in a component deployment descriptor, for example in a <tt>[[web.xml]]</tt> deployment descriptor for a web module, as shown below:
where "io.example.ServletA" is the class that declares the field. More details on @Resource annotation usage are available here {{Internal|@javax.annotation.Resource#name|@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. If a configuration value is specified in the component's deployment descriptor, for example in a <tt>[[web.xml]]</tt> deployment descriptor for a web module, as shown below:


<pre>
<pre>
Line 54: Line 62:
</pre>
</pre>


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


<pre>
<pre>
Line 64: Line 72:
</pre>
</pre>


The environment entry is available in each component's ""java:comp/env", and it is also available in "java:module/env", because it was declared in a module-level deployment descriptor. It won't be available in "java:app/env" or in "java:global", though.


 
=Environment Entry Types=
 
 
 
. Examples of such dependencies are:
 


==Simple Environment Entry==
==Simple Environment Entry==
 
==EJB References==
Applications use ''simple environment entries'' do declare a dependency on an external configuration parameter. Examples of such dependencies are:
==Persistence Unit References==
 
==Persistence Context References==
<pre>
==Resource Manager ConnectionFactory References==
@Resource
==Message Destination References==
private int configurationParameterA;
==Web Service References==
</pre>
==Resource Environment References==
 
==UserTransaction References==
 
==TransactionSynchronizationRegistry References==
For more details on @Resource semantics and defaults, see [[@javax.annotation.Resource]].
==ORB References==


=TODO=
=TODO=


<font color=red>
{{Error|<br><center>Desktop/Learning/NOKB TODO/JEE Core Concepts - Resources, Naming and Injection/JEE Core Concepts - Resources, Naming and Injection TODO.docx</center>}}
 
* Review [[WildFly JNDI Concepts]].
* Review [[@javax.annotation.Resource]]
* Review [[EJB_Annotations#.40javax.ejb.EJB]]
* Try to bind entries in jboss-app.xml, jboss-web.xml, etc.
 
</font>

Latest revision as of 01:08, 19 April 2017

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. Typically, application behavior can be changed externally by providing different parameter values or connecting the application with different 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.

Application Component Environment.png

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

@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. If a configuration value is specified in the component's 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>

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");

...

The environment entry is available in each component's ""java:comp/env", and it is also available in "java:module/env", because it was declared in a module-level deployment descriptor. It won't be available in "java:app/env" or in "java:global", though.

Environment Entry Types

Simple Environment Entry

EJB References

Persistence Unit References

Persistence Context References

Resource Manager ConnectionFactory References

Message Destination References

Web Service References

Resource Environment References

UserTransaction References

TransactionSynchronizationRegistry References

ORB References

TODO



Desktop/Learning/NOKB TODO/JEE Core Concepts - Resources, Naming and Injection/JEE Core Concepts - Resources, Naming and Injection TODO.docx