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

[<jue...@we...>]

Colin,
=20
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.
=20
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.
=20
Juergen
=20

________________________________

Von: Colin Sampaleanu [mailto:col...@ex...]
Gesendet: So 15.02.2004 23:44
An: j=FCrgen h=F6ller [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=3Dtrue the
default for the AbstractJndiLocator.

While most people will of course be running in a container, having a
default value of inContainer=3Dtrue will not help them, and will make
their config work harder. inContainer=3Dtrue 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=3Dfalse, otherwise the code will add
the java:comp/env/. That means that for every EJB proxy I need to add
inContainer=3Dfalse 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=3Dtrue.

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=FCrgen h=F6ller [werk3AT] wrote:

>Just fixed: inContainer=3Dtrue 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=FCrgen h=F6ller [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=FCrgen h=F6ller [werk3AT] wrote:
>
>=20
>
>>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=FCngliche 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
>>    =20
>>    =20
>>
>>      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
>>    =20
>>      As well, you may want to look up something on JNDI using another =
scheme
>>      entirely...
>>    =20
>>      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.
>>    =20
>>      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.
>>    =20
>>      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.
>>    =20
>>      Regards,
>>      Colin
>>    =20
>>