About Question enthuware.oce-ejbd.v6.1.351 :

[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".

[admin]

Fixed. Thanks for the feedback!

[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.

[admin]

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.

[Guest]

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?

[admin]

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.

[Guest]

[ 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.

[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.

[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.