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

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

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
>>	
>>