Re: [jboss-as7-dev] PART 3! of EJB Remote client design

Comments inline. On Thursday 22 September 2011 10:30 AM, David M. Lloyd wrote: > Client JNDI Revisited! > ---------------------- > > Based on feedback here and in IRC, we're changing our approach to client > EJB thus: > > A new JNDI "scheme" will be introduced called "ejb". Lookups into this > scheme following a naming convention will yield remote EJB proxies > directly. If the interface is not stateful, then the proxy is > immediately available without a server round-trip. > > The format for "ejb" scheme names is like this (square brackets are not > literal; they indicate that the enclosed section is optional): > > "ejb:appname/modulename/[distinctname/]beanname!interface[?stateful]" The appname (assuming it's the .ear name that we talking of, like in the spec) should be optional too, isn't it? Although making appname optional might end up with non-deterministic jndi name like: ejb:a/b/c!interface and we wouldn't know whether: 1) "a" is appname and "b" is module name or 2) "a" is module name and "b" is distinct name

> > The "appname", "modulename", and "distinctname" are the identifying > names of the EJB deployment. "beanname" is the EJB-spec name of the > EJB. "interface" is the Java type name of the interface being returned. > The "?stateful" query parameter indicates that a session should be > initiated on lookup. > > Since it is likely that users will erroneously use "?stateful" on a > stateful home interface (which is itself stateless), the lookup code > will detect whether the interface extends EJBHome before attempting to > initiate session, and if found will instead emit a warning. What about a case where the user adds a "?stateful" to a SLSB jndi name and we end up doing a server trip and realize it's a SLSB. Do we throw an error or just log a WARN?

> > This gives us configuration-free JNDI. Also, it gives us a JNDI name > scheme we can use in server-side EJB references as a lookup-name which > can create dependency-free injections of remote EJBs that may not be > present on the current system. And it's also nice in that it doesn't > interfere with "java:" spec lookups at all. I didn't understand the dependency-free injection part, but I guess what you are saying is that having a new ejb: scheme has an additional advantage too? Furthermore, I'm not a JNDI expert, so I might be missing some basic details. But why not treat "java:global" just like we would treat this new "ejb:" scheme? Is it the namespace "java:" and its traditional meaning that it's a in-VM namespace? I mean why do we need a new "ejb:" scheme for remote clients? Furthermore, although the EJB3 spec or other spec doesn't say anything for/against using the EJB3.1 spec mandated JNDI name scheme (java:global) from remote JVMs, I think some other app servers (GlassFish?) do allow these JNDI names to be used from a remote client. EJB3.1 spec Global JNDI section talks about portable JNDI names, so I'm not sure whether not supporting java:global from a remote client is right or wrong.

On a slightly different but related note - I believe we'll be backing this client JNDI impl on our EJB remote client API which uses EJBClientContext to select a target when a proxy is invoked. The design for that mandates that a (correct) EJBClientContext be associated with the caller thread. So in case of JNDI invocation which would look like: MyEJB proxy = InitialContext.doLookup("ejb:app/module/bean!intf"); proxy.echo("hello"); Is the client still expected to set the EJBClientContext before the proxy invocation? If not, how would we associate a EJBClientContext (with the right set of EJB receivers) for the invocation? Does the jndi.properties and the properties passed to InitialContext constructor play any role in deciding the set of EJB receivers that are available in the EJBClientContext? -Jaikiran _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev