JEE Core Concepts - Resources, Naming and Injection: Difference between revisions
(→TODO) |
|||
(13 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 | 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: | ||
<pre> | <pre> | ||
Line 38: | Line 40: | ||
... | ... | ||
<env-entry> | <env-entry> | ||
<env-entry-name>io. | <env-entry-name>io.example.ServletA/configurationParameterA</env-entry-name> | ||
<env-entry-type>java.lang.Integer</env-entry-type> | <env-entry-type>java.lang.Integer</env-entry-type> | ||
<env-entry-value>11</env-entry-value> | <env-entry-value>11</env-entry-value> | ||
Line 45: | Line 47: | ||
</pre> | </pre> | ||
More details on @Resource annotation usage are available here | 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: | |||
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. | |||
<pre> | <pre> | ||
Line 64: | Line 62: | ||
</pre> | </pre> | ||
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 74: | 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= | |||
==Simple Environment Entry== | ==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= | =TODO= | ||
< | {{Error|<br><center>Desktop/Learning/NOKB TODO/JEE Core Concepts - Resources, Naming and Injection/JEE Core Concepts - Resources, Naming and Injection TODO.docx</center>}} | ||
</ |
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.
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
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