Re: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others

[Colin S. <col...@ex...>]

What I don't like about checking both locations is that you then end up 
doing two checks every single time really, for one of the most common 
cases. I'm also not sure it's that correct to check in two places when 
you tell it one... It would certainly work though.

I'm curious just how much existing usage would break. I don't think it's 
much of an issue for EJB access. Most people don't map their EJBs to the 
local namespace. For datasource access, JBoss puts those into 
'java:xxxxx', not just 'xxxxx', no choice in the matter, so JBoss users 
would not be affected at all. It's been a while since I've used WebLogic 
so I don't remember where WebLogic datasources end up.

It's unfortunate that it's this late in the game, since it's pretty 
clear to me that the best default state for this optimization (default 
adding of java:comp/env) is best off, if we didn't have the 
compatibility concern... We could perhaps try to get an idea of how many 
users actually have configs where they are relying on this. The answer 
we get back would probably be scalable towards the whole user base....

Colin

jürgen höller [werk3AT] wrote:

>Colin,
> 
>While I generally agree that it's more appropriate to have "inContainer" default to false, I'm a bit worried that such a change would break all bean definition files that currently rely on accessing container DataSources with that implicit prefix.
> 
>A further option would be to change "inContainer"'s semantics to: check for "java:comp/env/myJndiName" first, then try "myJndiName" directly if the former was not found. That would catch both cases, being fully backward-compatible, with just minimal overhead at startup. "inContainer"  turned off would solely try the latter case.
> 
>Juergen
> 
>
>________________________________
>
>Von: Colin Sampaleanu [mailto:col...@ex...]
>Gesendet: So 15.02.2004 23:44
>An: jürgen höller [werk3AT]
>Cc: spr...@li...
>Betreff: Re: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others
>
>
>
>I think we should revisit the decision to make inContainer=true the
>default for the AbstractJndiLocator.
>
>While most people will of course be running in a container, having a
>default value of inContainer=true will not help them, and will make
>their config work harder. inContainer=true helps only if by default your
>code is something like an EJB or WebApp, and you want to save typing
>'java:comp/env/' at the beginning of your resource names, _and_ you have
>gone to the pain of doing a resource mapping to bring resources into the
>local java:comp/env/ namespace, something that most people don't bother
>doing.
>
>If I deploy an EJB in JBoss for example, it gets deployed into the
>global (not even 'java:') namspace. Unless I do the resource-ref mapping
>for the client code that needs to access it, it needs to be accessed via
>the global namespace. Since there is no prefix at all, that's completely
>impossible to do unless inContainer=false, otherwise the code will add
>the java:comp/env/. That means that for every EJB proxy I need to add
>inContainer=false as a property.
>
>If false was the default, then people accessing resources for which
>there was a local resource mapping (again, people don't usually do this)
>would still have the choice of either using the full
>  java:/comp/env/
>prefix, and leaving inContainer unset, or just setting
>  inContainer=true.
>
>I think this change makes sense because locally mapped resources (to
>java:/comp/env) are less common than non-mapped resources. What do you
>think?
>
>Regards,
>Colin
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Just fixed: inContainer=true does not prepend the container prefix if a scheme is given (i.e. a ":" contained).
>>
>>
>>-----Original Message-----
>>From: Colin Sampaleanu [mailto:col...@ex...]
>>Sent: Friday, August 22, 2003 1:33 PM
>>To: jürgen höller [werk3AT]
>>Cc: spr...@li...
>>Subject: Re: [Springframework-developer] AbstractJndiLocator should not
>>assume java:comp/env prefix while not allowing others
>>
>>
>>I somehow missed the inContainer property, even though I looked at the
>>source!   I think it does make sense though to add the check for the
>>scheme as per your and mine suggestion; even in a container you still
>>need to be able to override this...
>>
>>Regards,
>>Colin
>>
>>jürgen höller [werk3AT] wrote:
>>
>>
>>
>>    
>>
>>>Hi Colin,
>>>
>>>AbstractJndiLocator only does so when the "inContainer" property is set to true (the default). Setting this property to false should result in looking up the JNDI name as is. It could make sense to add a check for scheme though, e.g. only apply "java:comp/env/" if "inContainer" is true *and* the JNDI name does not contain a ":". What do you think?
>>>
>>>Juergen
>>>
>>>
>>>     -----Ursprüngliche Nachricht-----
>>>     Von: Colin Sampaleanu [mailto:col...@ex...]
>>>     Gesendet: Fr 22.08.2003 05:43
>>>     An: spr...@li...
>>>     Cc:
>>>     Betreff: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others
>>>    
>>>    
>>>
>>>     AbstractJndiLocator right now looks at the jndi name it is given, and if
>>>     it doesn't start with
>>>        java:comp/env
>>>     prepends this value automatically. This behaviour is not correct.
>>>     Somebody using the bean should be able to look up resources anywhere,
>>>     and currently you can't. For example, in jboss, the main datasource by
>>>     default is bound to
>>>       java:DefaultDS
>>>    
>>>     As well, you may want to look up something on JNDI using another scheme
>>>     entirely...
>>>    
>>>     What the code should probably do is see if the is a scheme
>>>        xxxxx:
>>>     at the beginning of the jndi name. If there isn't, then it is probably
>>>     reasonable to assume 'java:comp/env. or 'java:' If there is a scheme, it
>>>     should leave the name alone.
>>>    
>>>     I would have supplied a patch, but the fix is trivial, and I don't know
>>>     how exactly you want to handle this, but it's pretty critical to me.
>>>    
>>>     Right now with JBoss it's pretty nasty. I can not use JBoss's naming
>>>     alias service to alias
>>>       java:comp/env/DefaultDS
>>>     to
>>>       java:DefaultDS
>>>     because it apparently doesn't let you alias stuff under comp/env.  I can
>>>     probably modify my resource entries in the war file I use to do a
>>>     resource ref to the right location, but I would really rather not do
>>>     that, since the war is fine the way it is.
>>>    
>>>     Regards,
>>>     Colin
>>>    
>>>