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

On 09/22/2011 07:00 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", "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. Both a SLSB and a SFSB can have an EJBHome interface for their remote home view. So I don't see how this can play a role in determining the session characteristic. In fact a call to a home view is always session-less, both for SLSB and SFSB. The proxy returned by the create method represents the possible session.

> 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. > > This should address all the issues raised with client JNDI thus far. > Binding the URL ObjectFactory to java:something would result in exactly the same functionality. We can still offer this choice to users.