Page 1 of 1
About Question enthuware.oce-ejbd.v6.1.351 :
Posted: Tue Apr 19, 2011 9:11 am
by ETS User
In the explanation of the third question, what does
int mean? Perhaps internal?
Notice the missing jdbc. It should be "java:comp/env/jdbc/oceejbd". All locally used JNDI names are also available to the bean int "java:comp/env" name space. Thus, "jdbc/oceejbd" will also be available using "java:comp/env/jdbc/oceejbd".
Re: About Question enthuware.oce-ejbd.v6.1.351 :
Posted: Tue Apr 19, 2011 8:09 pm
by admin
Fixed. Thanks for the feedback!
Re: About Question enthuware.oce-ejbd.v6.1.351 :
Posted: Sun Oct 07, 2012 9:01 am
by Guest
It is not that I am too lazy to try, but rather that I don't trust my skill at trying.
Isn't it true that JNDI names are "by convention"? So, you might register your data source as java:comp/env/oceejbd, and an explicitlookup would find it? Some third-party applications, such as admin interface, would probably break over it, but the core functionality should do okay.
If that is true, then the third choice is also acceptable.
Re: About Question enthuware.oce-ejbd.v6.1.351 :
Posted: Sun Oct 07, 2012 11:28 am
by admin
Guest wrote:It is not that I am too lazy to try, but rather that I don't trust my skill at trying.
Isn't it true that JNDI names are "by convention"? So, you might register your data source as java:comp/env/oceejbd, and an explicitlookup would find it? Some third-party applications, such as admin interface, would probably break over it, but the core functionality should do okay.
If that is true, then the third choice is also acceptable.
It is true that it is just a convention and you name it anything. But that logic doesn't apply here because the name given in the code in @Resource is "jdbc/oceejbd". So you cannot omit /jdbc while looking it up in jndi name space.
HTH,
Paul.
Re: About Question enthuware.oce-ejbd.v6.1.351 :
Posted: Sun Oct 07, 2012 12:25 pm
by Guest
admin wrote:But that logic doesn't apply here because the name given in the code in @Resource is "jdbc/oceejbd".
Well, it is not explicitly required that I reference _the same_ data source inside the method. In fact, it would be more realistic to look up a different data source to use in conjunction with the class-injected one.
There is no rule against resources having the same unqualified name, if you pardon the expression?
Re: About Question enthuware.oce-ejbd.v6.1.351 :
Posted: Sun Oct 07, 2012 1:15 pm
by admin
Guest wrote:admin wrote:But that logic doesn't apply here because the name given in the code in @Resource is "jdbc/oceejbd".
Well, it is not explicitly required that I reference _the same_ data source inside the method. In fact, it would be more realistic to look up a different data source to use in conjunction with the class-injected one.
There is no rule against resources having the same unqualified name, if you pardon the expression?
I see your point but in that case your answer depends on information that is not provided with the question. Typically, if a question tries to test you on how to look up a value defined in the environment, in its jndi name space, it would specify how that value is defined in the environment by showing the relevant deployment descriptor text. The given question doesn't mention anything. But by your logic, any value in sctx.lookup(...), would be valid.
HTH,
Paul.
Re: About Question enthuware.oce-ejbd.v6.1.351 :
Posted: Sun Oct 07, 2012 1:44 pm
by Guest
admin wrote:[ But by your logic, any value in sctx.lookup(...), would be valid.
My point exactly. The questions often test us against the limits of possibility - which poorly written code is still valid, and which is beyond salvation. In this case this would be, I suppose, a lookup with a completely unacceptable jndi name.
Or you could specify, that the developer wants to look up the same data source as he has already injected.
In fact, the question is good as it is now - but, perhaps, a note in the explanation on this issue would not be extraneous.
Re: About Question enthuware.oce-ejbd.v6.1.351 :
Posted: Tue May 05, 2015 7:46 pm
by himaiMinh
According to the specification, SessionContext.lookup looks for a JNDI name relative to java:comp/env while InitialContext looks for a complete JNDI name such as java:comp/env/....
So, if we use SessionContext.lookup, it should not include java:comp/env ?
For option 3, in the explanation , I don't think java:comp/envjdbc/oceejdb works for SessionContext.lookup. Instead, it will only work for InitialContext lookup.
Re: About Question enthuware.oce-ejbd.v6.1.351 :
Posted: Tue May 05, 2015 7:57 pm
by himaiMinh
I can answer my own question. Form the JEE API , it says:
Object lookup(String name)
throws IllegalArgumentException
Lookup a resource within the java: namespace. Names referring to entries within the private component namespace can be passed as unqualified strings. In that case the lookup will be relative to "java:comp/env/". For example, assuming an enterprise bean defines an ejb-local-ref with ejb-ref-name "ejb/BarRef" the following two calls to EJBContext.lookup are equivalent : ejbContext.lookup("ejb/BarRef"); ejbContext.lookup("java:comp/env/ejb/BarRef");
So, look up by java:comp/env/.... or just the name relative to that namespace will work.
The explanation is true.