geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Global JNDI effectively required for Jee5
Date Wed, 07 Feb 2007 20:06:04 GMT
On Feb 7, 2007, at 10:51 AM, David Jencks wrote:

> On Feb 7, 2007, at 9:54 AM, Dain Sundstrom wrote:
>> On Feb 7, 2007, at 8:01 AM, David Jencks wrote:
>>>> 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.
>> um, I'm not making that assumption.  I'm assuming that other  
>> systems are using Global JNDI for resolving refs and that users  
>> will have "normal" JNDI names hardcoded into their apps.  By  
>> normal names I would say that they are simple words separated by a  
>> '/' character.
> I'm saying:
> 1. simple names are good
> 2. simple names have nothing necessarily to do with  global jndi  
> althought that is one possible implementation strategy
> 3. if users expect portability across app servers we need to do  
> some actual research on what other app servers do and find out if  
> there is in fact a de-facto standard.  Hand waving won't cut it.

I did do resarch, but the data will not be satisfactory to you.  The  
only server with formal docs on this is Glasfish and they use Global  
JNDI as I described.  As for the other servers, they have posts to  
mailing lists that clearly imply that they have implemented mapped  
name the same way that Glassfish did.  Alternatively, I can not think  
of a single appserver other then Geronimo that doesn't make extensive  
use of Global JNDI.

>>>> So do you agree that Global JNDI is the defacto required  
>>>> implementation for these and other similar entries?
>>> no.
>>> 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.
>> I understand your reluctance and know the history, but reality is  
>> *everyone* uses Global JNDI.  I challenge you to find a single JEE  
>> server that doesn't.  Since everyone does, it is the defacto  
>> standard, and it is becoming more ingrained into the specs.  I  
>> think we need give up on our custom system, and simply implement  
>> it the way everyone else dose.
> I don't really understand what your insistence on global jndi has  
> to do with the problem of resolving these annotations.  The user's  
> app isn't directly using jndi for this.  To me you are saying "we  
> can't do anything better than anyone else because it might be  
> different".

But they do use Global JNDI also.  We have tons of posts to the users  
list from confused new users that can't figure out how to specify  
Global JNDI names for data sources.  I believe that the introduction  
of mappedName in JEE5 is the proverbial straw, and we should just use  
Global JNDI and be done with it.

>>> 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.
>> There is nothing wrong with either proposal, and either would be a  
>> step forward.  I just think we shouldn't invent something new and  
>> just give users what they expect.
> Do you think (2) would surprise people too much?  I'm very  
> reluctant to abandon the conflict avoidance of what we have in  
> order to copy the lowest common denominator.  (1) is the easiest  
> solution I can think of since it's basically already implemented  
> and doesn't involve coming up with a binding strategy for  
> everything and (2) seems to me to combine the advantages of global  
> jndi with the conflict avoidance we have now.  Why is plain global  
> jndi better?

I am not saying that Global JNDI is better.  I'm saying it is the  
norm.  People are used to the problem of JNDI and have procedures to  
avoid naming conflicts.  When they have naming problems  
(NameNotFoundException) they have tools (e.g., JNDI browser, JNDI  
dump, etc) to debug the problem and known how to fix it (change the  


View raw message