You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by "Chad Schoettger (JIRA)" <de...@beehive.apache.org> on 2006/09/20 22:20:22 UTC
[jira] Assigned: (BEEHIVE-888) Provide way to use java:comp/env
lookups for resource based controls
[ http://issues.apache.org/jira/browse/BEEHIVE-888?page=all ]
Chad Schoettger reassigned BEEHIVE-888:
---------------------------------------
Assignee: Chad Schoettger (was: Mike Foster)
> Provide way to use java:comp/env lookups for resource based controls
> --------------------------------------------------------------------
>
> Key: BEEHIVE-888
> URL: http://issues.apache.org/jira/browse/BEEHIVE-888
> Project: Beehive
> Issue Type: Improvement
> Components: Controls
> Reporter: David Read
> Assigned To: Chad Schoettger
> Priority: Minor
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira