Hi Frank, You are right about the way you interpreted the spec regarding binding beans for lookup locally.
> So, how does a servlet or jsp lookup a local interface? I do not recall (and > do not have the servlet/jsp spec handy) if java:comp/env is used by jsps and > servlets. But even if they are, I do not recall jsps needing a deployment > descriptor that would declare local ejb references. So how does a jsp/servlet > lookup local references? JSPs can lookup EJB local interfaces locally just as any other collocated EJBs would. You do need a deployment descriptor for that. For your web components to lookup EJBs in this way, you'd need a web.xml to declare the ejb-refs and then map them in your server specific descriptors. ----- Original Message ----- From: "Frank Gates" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 28, 2003 10:03 PM Subject: Re: how not to look up local Ejbs > Krish, > > Your discussion is very interesting and informative, yet I was a little > confused by your assertion that all local ejb references are handled > differently than remote references. The EJB 2.0 spec has this statement: > > 20.3.1.1 EJB reference programming interfaces > > The EJB specification recommends, but does not require, that all references > to other enterprise > beans be organized in the ejb subcontext of the bean's environment (i.e., > in the > java:comp/env/ejb JNDI context). > > And, in that same section, the spec states that : > > 20.3.1.2 Declaration of EJB references in deployment descriptor > > An EJB reference is scoped to the enterprise bean whose declaration > contains the ejb-ref or > ejb-local-ref element. This means that the EJB reference is not accessible > to other enterprise > beans at runtime, and that other enterprise beans may define ejb-ref and/or > ejb-local-ref ele-ments > with the same ejb-ref-name without causing a name conflict. > > While the ejb remote and local references are required to be declared by the > Bean Provider and are scoped to that bean's naming context (java:comp/env), the > spec still does not require that they be looked up using java:comp/env/ejb. > > I was momentarily confused by the first statement (20.3.1.1), and maybe > appserver writers are, too. It appears that the spec did not require that ejb > references be bound to java:comp/env. But that is not what it is saying. > The statement is that they recommend that ejb references (local and remote) be > bound to a subcontext named "ejb". Deployers could use a context named > "lord_of_the_rings" to store references if they wanted to, but it must be > rooted from java:comp/env. > > Another point of confusion is how none-ejb clients lookup ejb references. In > Chapter 5 it states: > > Chapter 5 Local, Remote, and Web Service Client Views > 5.3 Local Clients > > Session and entity beans may have local clients. A local client is a client > that is collocated in the same > JVM with the session or entity bean that provides the local client view and > which may be tightly cou-pled > to the bean. A local client of a session bean or an entity bean may be > another enterprise bean (a ses-sion > bean, entity bean, or message-driven bean) or a web component. > > As I understand it, ejbs and web services must use java:comp/env to lookup > other ejbs and that local references for session and entity beans are available > to other ejbs. Web components (jsp's and servlets) may lookup local > interfaces if they are located in the same JVM, but other ejb clients > (applications and remote jsp's and servlets) must use the remote home > interfaces found in the global jndi bindings. > > So, how does a servlet or jsp lookup a local interface? I do not recall (and > do not have the servlet/jsp spec handy) if java:comp/env is used by jsps and > servlets. But even if they are, I do not recall jsps needing a deployment > descriptor that would declare local ejb references. So how does a jsp/servlet > lookup local references? > > Thanks, > > Frank Gates > Geneva Project > > > Krishnan Subramanian wrote: > > > Hemant, > > > > I know its hard when people argue that AppServer X supports it. > > Our response has been that it's a bug in X. And then the same > > people come back a few days later to claim AppServer Y supports > > it as well! And my response usually is: "Now you know it's a > > bug in Y as well!" *grin* > > > > But, given a lot of migrations (from X & Y ;) to our product, > > we've had to introduce a plug-in that lets these messed up > > JNDI calls work in our product (sometimes source code is not > > available). Its saved our customers some effort in the migration > > process and probably is the first time we've knowingly introduced > > a bug into our product. > > > > -krish > > Borland > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > Sent: 28 February 2003 12:18 > > > To: [EMAIL PROTECTED] > > > Cc: [EMAIL PROTECTED] > > > Subject: Re: how not to look up local Ejbs > > > > > > > > > A direct JNDI name lookup on the local interface does not > > > make much sense. > > > But when clients say app server X is supporting this, its > > > pretty difficult > > > to drive the point. Anyway we survived the temptation :-). > > > > > > cheers, > > > Hemant > > > www.pramati.com > > > > > > > All, > > > > > > > > Many EJB developers who are building applications based on > > > > the EJB 2.x specification seem to be making this (serious) > > > > mistake; and worse do not realize that their code is relying > > > > on an AppServer bug. > > > > > > > > The problem itself is a simple one: > > > > > > > > When looking up an EJB with local interfaces, developers use > > > > the physical JNDI name of the local enterprise bean in lieu > > > > of the specification defined environment naming context(ENC). > > > > > > > > For example: assume a local entity bean with fully qualified > > > > package name: com.mycompany.employee.ejb.EmployeeEjbHome > > > > and any unique local JNDI name (say): EmployeeEjb. This > > > > name could also be the fully qualified class name - which > > > > many seem to prefer. > > > > > > > > And the code developers tend to write to lookup this local > > > > bean from a caller (say another EJB / Servlet etc,.) is: > > > > > > > > javax.naming.Context jndiContext = > > > > new javax.naming.InitialContext(); > > > > Object localRef = jndiContext.lookup("EmployeeEjb"); > > > > > > > > Unfortunately, the above code is not right. The fact that it > > > > works in your AppServer would be an AppServer bug. Let me > > > > explain: > > > > > > > > There are two 'spaces' where you could register resources. One > > > > in the naming service (globally accessible) - and other in the > > > > environment naming context (ENC) of a bean. The ENC is private > > > > to that bean. So, while the underlying implementations are > > > > different, the API (JNDI) used to access both are the same. > > > > > > > > The distinguishing factor between the two - is that resources > > > > registered in the ENC begin with the prefix "java:comp/env/". > > > > And the Container 'knows' that any lookup performed with the > > > > "java:comp/env/..." prefix must be routed to the ENC of that > > > > bean, while any other would go to the naming service. > > > > > > > > To visualize things, you could think of the ENC as a cute little > > > > naming service for every bean - in which you can register > > > whatever you > > > > want [only that bean] to access. > > > > > > > > Depending on the naming service implementation (LDAP | COSNaming > > > > | whatever), calls to the naming service might span processes; > > > > while those to the ENC will [never] do so. Or in other words, > > > > calls to the ENC are always intra-process calls, while the same > > > > [cannot] be guaranteed with the naming service given that it is > > > > AppServer vendor specific. > > > > > > > > Since the naming service implementation is vendor specific and > > > > potentially could be either Centralized/Distributed/Homogeneous > > > > across AppServer processes, you cannot register process specific > > > > (or local) resources here. And to make matters complicated > > > > (depending on your view of course), many AppServer vendors offer > > > > your own option (Central/ Distributed/Homogeneous) while setting > > > > up the naming service (at least we - Borland - do) based on your > > > > needs/preferences. > > > > > > > > Which brings us to the question - if I cannot use the global JNDI > > > > tree, how do I lookup local EJBs? The answer lies in using the > > > > ENC via EJB Local References entries. EJB Local References are > > > > defined in the deployment descriptor part of the caller bean and > > > > point to the local bean that is the target of the lookup. So > > > > assuming you gave the EJB Local References a name such as > > > > "ejb/EmployeeEjb" and pointed to the Employee local EJB, then > > > > the above local bean can be looked up in the ENC of the caller > > > > by appending the "java:comp/env/" prefix to the string. So, now > > > > your code for looking up a local bean would be: > > > > > > > > javax.naming.Context jndiContext = > > > > new javax.naming.InitialContext(); > > > > Object localRef = jndiContext.lookup( > > > > "java:comp/env/ejb/EmployeeEjb"); > > > > > > > > I wonder if developers actually use the above spec compliant > > > > and portable mechanism of performing a lookup on a local bean? > > > > > > > > I'd be interested in other thoughts on this. Unfortunately, not > > > > many books/articles I've come across explain these concepts in > > > > sufficient detail. > > > > > > > > -krish > > > > > > > > > > > ============================================================== > > > ============= > > > > To unsubscribe, send email to [EMAIL PROTECTED] and > > > include in the > > > > body of the message "signoff EJB-INTEREST". For general help, send > > > > email to [EMAIL PROTECTED] and include in the body of > > > the message > > > > "help". > > > > > > > > > > > > > > > > > > > =========================================================================== > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > > of the message "signoff EJB-INTEREST". For general help, send email to > > [EMAIL PROTECTED] and include in the body of the message "help". > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
