beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chad Schoettger (JIRA)" <...@beehive.apache.org>
Subject [jira] Assigned: (BEEHIVE-888) Provide way to use java:comp/env lookups for resource based controls
Date Wed, 20 Sep 2006 20:20:22 GMT
     [ 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

        

Mime
View raw message