Details
-
Improvement
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
None
-
None
-
None
Description
As far as I can tell, the JNDI names used in annotations for controls (e.g. JMS, JDBC, EJB) are assumed to be "global" JNDI names. In simple deployment environments, this works fine. However, there are some cases where administrators want to be able to bind to a different global JNDI name as part of production deployment. In that case, the use of component environment lookup allows developers to use an "alias" for the JNDI name (e.g. java:comp/env/jms/OrderCancelledQueue). Administrators then use vendor specific deployment descriptors to map the alias to the right "thing".
Mapping is accomplished for resource factories via <resource-ref> elements, and for administrative objects via <resource-env-ref> elements in the standard descriptors (e.g. web.xml). This approach of using an "alias" for JNDI names looks even more useful with the appearance of JSR88. Administrators now have a means to configure an application as part of deployment ... without having to directly modify the descriptors inside the application/module.
Seems like supporting this would require a few things. (1) assembly would have to "see" that the form of lookup being used was java:comp/env (2) a new annotation that would hold the global JNDI name. (3) validation of annotations should probably enforce that a JNDI name with java:comp/env as a prefix requires a value in the "other" JNDI annotation, and the "other" JNDI annotation value is not allowed unless the JNDI name begins with java:comp/env.
It might be possible to munge both values (JNDI names) into the current JNDI annotation, but that might make tooling support a bit more difficult. I don't think there's any change to the control implementations. They just continue to "lookup" the value in the current annotation. It's an assembly task to get the descriptors right, and the container's job to follow the mapping at runtime.