Not the whole story, Dont have it in mind exactly but you need both because fron ee tomcat components it is hitten from comp/env and from the rest of the app with the real name (spring for instance to our integration
Think we have it too in our integration since we use openejb/resource and in tomcat integ where we merge in comp/env...but works for ee injections What the issue with this rebinding? Le 30 nov. 2012 01:14, "David Blevins" <david.blev...@gmail.com> a écrit : > Moving the discussion to the dev list. Seems there's some confusion on > the rules around "java:app" visibility. > > From a purely specification and compliance perspective, the basic rule is > that "java:app" is visible to the entire application, universally. No > exceptions and no conditions. If it is running *inside* the application, > it can do lookups from "java:app" > > The confusing part comes in that the same is not true for *declaring* > these names. To be specific `@Resource` is effectively only available to > Java EE components. So, non-JavaEE components effectively cannot declare > names to be added to "java:app", nor can they get dependency injection via > `@Resource` > > Easy to get confused. > > From an implementation perspective, right, Tomcat does not add "java:app" > names. I suspect this, in combination with the above non-intuative rules > about declaring vs using java:app names, is the source of the confusion on > TOMEE-597. > > It seems possible Tomcat misinterprets "java:app/Foo" names and binds them > to "java:comp/env/app/Foo", in which case we should likely remove the > non-portable "java:comp/env/app/Foo" binding. Effectively, it's a Tomcat > bug from not understanding the new "java:app" namespace. > > We definitely shouldn't be merging "java:comp/env/app/" to "java:app/" if > we can avoid it. If there is some odd situation in the integration that is > causing this idiosyncrasy, we should do our best to eliminate it. > > > -David > >
