Menu
▾
▴
RE: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others
|
From: <jue...@we...> - 2004-02-16 13:21:48
|
I agree that such a double check is not too desirable - a bit too much = magic behind the scenes. On second thought, I'm not sure if "inContainer" defaulting to true is = so inappropriate after all. Standard J2EE requires <resource-ref> = declarations in web.xml, expecting "jdbc/myds"-style names relative to = "java:comp/env"; the default AbstractJndiLocator accepts the same name = syntax. I can imagine that quite a few users consider this intuitive - = and I tend to agree... Remember that if you use "xxx:"-style JNDI prefixes, you won't get the = "inContainer" behavior in any case. So I'm not sure how many scenarios = actually require setting "inContainer" to false currently. Even JBoss = JNDI locations for JDBC DataSources (in "-ds.xml" files) are = automatically relative to the "java:" prefix. So is it just about = default EJB locations in JBoss? Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Colin Sampaleanu Sent: Monday, February 16, 2004 1:44 PM To: spr...@li... Subject: Re: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others What I don't like about checking both locations is that you then end up=20 doing two checks every single time really, for one of the most common=20 cases. I'm also not sure it's that correct to check in two places when=20 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=20 'java:xxxxx', not just 'xxxxx', no choice in the matter, so JBoss users=20 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=20 clear to me that the best default state for this optimization (default=20 adding of java:comp/env) is best off, if we didn't have the=20 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=20 we get back would probably be scalable towards the whole user base.... Colin j=FCrgen h=F6ller [werk3AT] wrote: >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: > > =20 > >>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 >>> ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
