Menu
▾
▴
Re: [Springframework-developer] AbstractJndiLocator should not assume java:comp/env prefix while not allowing others
|
From: Colin S. <col...@ex...> - 2004-02-17 03:01:01
|
Nobody forces resource-ref declarations on you, lots of people run without them. They are a way to ensure that a particular component can actually be found in a know location as far as another component is concerned, given that the default binding location may be container specific. But for a lot of people it's easier to just configure for the specific location in the app server, instead of setting up all these resource-ref declarations... What I don't like about it is the idea that a default setting is playing around with the path you feed the function, and short of adding the extra property you can't even override it with another path format, wheras the reverse is not true; if the default was off, even without setting the property to on you could still just use the full path to get the local binding. The JBoss JMS queue is also bound without any prefix. I just took a look at an old config of mine from when I was running WebLogic, and my datasources were bound in the global namespace, e.g. jdbc/Certification with no java: prefix. Same deal for the JMS queue, and same for the mail. Probably the thing to do is pose a question on the user list and see how many people are even relying on the inContainer=true auto-prefixing... Regards, Colin jürgen höller [werk3AT] wrote: >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 >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 >>>> >>>> >>>> >>>> |
