Hi, Jason
A similar discussion in this glassfish forum thread:
http://forums.java.net/jive/thread.jspa?threadID=15564&tstart=45
I've copy/paste Ken's answer for this below w.r.t jndi name for
remote view and local view.
Thanks,
- Hong
========================================================
The main reason a bean's remote EJB view is assigned a global JNDI name
is that it can be accessed from any application and from the client
tier. The Remote EJB global JNDI name is intended to be used to resolve
a remote ejb-ref/_at_EJB dependency to the actual target Remote EJB. It's
important to understand that any direct use of the global JNDI name in a
new InitialContext().lookup("global jndi name") is not portable. This is
a common point of confusion.
Any Java EE component (app client, web component, ejb) that looks up a
remote ejb should do so via java:comp/env or in the case of EJB the new
EJBContext.lookup() method. Directly accessing the global JNDI namespace
works in some cases but is not covered by the specs. This is true for
any kind of lookup. From a portability perspective, the global JNDI
namespace does not exist for the Java EE application.
In the Java EE SDK Local EJBs are only available from within web and EJB
components packaged within the same .ear as the target Local EJB. In
this case there's no need to assign the Local view a global JNDI name
since the target of an ejb-local-ref or local @EJB can always be
unambiguously identified using the ejb-link/beanName() syntax defined by
the spec. It's true that it would be a convenience to allow lookup
without defining the ejb-local-ref/_at_EJB dependency but doing so would
merely be adding a non-portable option, which we try to minimize.
It's very simple to define a local EJB dependency that can be looked up
via java:comp/env in the web tier. You can use the .xml approach and
just define an ejb-local-ref in web.xml. In the case of EJB 3.0 local
business interfaces, just leave off the local-home element.
Alternatively, define a class-level @EJB annotation in any managed class
in the .war. The component naming context is shared by the entire .war,
so defining the dependency makes it available to all code within the .war.
E.g.
@EJB(name="myejblocalref", beanInterface="com.acme.LocalIntf")
public class MyServlet .... {}
Then, any code within the .war can do
LocalIntf beanRef = (LocalIntf)
new InitialContext().lookup("java:comp/env/myejblocalref");
See
https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html for more
info on the treatment of EJB JNDI names in our implementation.
There's also a presentation that covers some of these topics available at
https://glassfish.dev.java.net/javaee5/ejb/compdependencies_xmlforum_nov15.pdf
================================
Jason Lee wrote:
>I'm having trouble grabbing a reference to a local session bean
>interface from a web app deployed to the app server as the session bean
>(thus the local reference). The session bean has this interface:
>
>@Local
>public interface ITestSession {
> void start() throws Exception;
>}
>
>If I mark that as @Remote, I can get the remote reference from an out of
>container client just fine using the class name as the JNDI lookup. I
>mark it as @Local, however, and try to look it up like this from my web
>app:
>
> Context ctx = new InitialContext();
> Object bean = ctx.lookup("com.iecokc.test.ITestSession"); //
>No cast need
>
>Which gets me "javax.naming.NameNotFoundException:
>com.iecokc.test.ITestSession not found". (For what it's worth,
>ITestSession is not in the web apps classpath, and I plan to be working
>against "bean" via reflection, so I won't explicitly reference the
>interface's class name.) If I try "java:comp/env/ejb/ITestSession" as
>the JNDI name as one (possibly old) reference I found, I get
>"javax.naming.NameNotFoundException: No object bound to name
>java:comp/env/ejb/ITestSession". What's the proper way to lookup the
>reference? Or is Glassfish smart enough to treat it as a local call
>even if I were to mark it as @Remote? I have the EJB3 spec PDFs in
>front of me, but I'm not seeing anything on the subject. Any hints,
>pointers, etc?
>
>I appreciate it!
>
>--
>Jason Lee
>Programmer/Analyst
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>