geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Global JNDI effectively required for Jee5
Date Wed, 07 Feb 2007 16:01:16 GMT

On Feb 6, 2007, at 5:34 PM, Dain Sundstrom wrote:

> Jee5 makes extensive use of Global JNDI for references.   
> Specifically, the following use Global JNDI:

It looks to me as if these all mention global jndi but saying they  
"use" global jndi seems like an exaggeration to me.

> @Resource.mappedName()
> This mapped name is often a global JNDI name, but may be a name of  
> any form.
> @EJB.mappedName()
> This mapped name is often a global JNDI name, but may be a name of  
> any form.
> @MessageDriven.mappedName()
> A product specific name(e.g. global JNDI name of a queue) that this  
> message-driven bean should be mapped to.
> @WebServiceRef.mappedName()
> This mapped name is often a global JNDI name, but may be a name of  
> any form.
> <persistence-unit><jta-data-source>
> <persistence-unit><non-jta-data-source>
> InJavaEEenvironments,thejta-data-sourceandnon-jta-data- 
> sourceelementsareused
> tospecifytheglobal JNDInameoftheJTAand/ornon- 
> JTAdatasourcetobeusedbythepersistence
> provider.
> The spec makes it clear that Global JNDI is not required to satisfy  
> these values, and that the meaning of these fields is completely  
> vendor specific.  In the case of mapped name, the application  
> server can completely ignore the field.
> The problem is our users' applications will make use of mapped name  
> in other application servers, and since every application server  
> that I know if is implementing these with Global JNDI, it becomes a  
> defacto standard and requirement for Jee5.  Moreover, I believe  
> that our GlobalJNDI names must be simple normal names (i.e, not  
> encoded abstract names) you would see in other application servers,  
> because users will annotate their code with the mapped names,  
> effectively locking in the Global JNDI names that they expect to  
> work in our application server.

umm, that assumes that either every other app server has come up with  
exactly the same scheme for global jndi names so they are in fact  
interoperable or that we can imitate everyone elses naming scheme at  
once.  Do you have any evidence for the first?  How would you propose  
we do the second?  What are the jndi naming schemes for each other  
app server?
> So do you agree that Global JNDI is the defacto required  
> implementation for these and other similar entries?


Since the beginning of geronimo we've carefully stayed away from  
relying on global jndi for  resolving references since it imposes  
global constraints on what you can deploy at once in the app server,  
despite every other app server I know of relying on global jndi for  
resolving references.  I'm extremely reluctant to abandon the lack of  
conflicts between apps that we have now to run after an alleged  
similarity with other app servers without thorough investigation of  
compatibility between other app servers and thinking about other  
choices that would preserve the lack of conflicts.

Note that the use of any particular style of name in such annotations  
does not imply that the target is actually bound in jndi: all it  
requires is that we can find the resource somehow.

Two alternatives that I would prefer to global jndi are:

1. We know the type of the thing we're looking for, so we can simply  
treat the provided string as an (extended) ejb-link, resource-link,  
etc and search the ancestor tree of the current app for a unique  
match.  IMO this would be a lot simpler to implement that relying on  
global jndi, because we already have the code implemented and don't  
have to bind anything anywhere.

2. "scoped" global jndi.  Each application gets a "global" jndi tree  
that only includes stuff from itself and its ancestor graph.  This  
avoids conflicts and should satisfy those with a jndi fetish.

david jencks

> -dain

View raw message