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

On 09/22/2011 08:59 AM, Carlo de Wolf wrote: > On 09/22/2011 03:21 PM, David M. Lloyd wrote: >> On 09/22/2011 03:52 AM, Carlo de Wolf wrote: >>> 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. >> >> That's what I said. EJBHome are always stateless. Therefore if >> ?stateful is given for an EJBHome, it is ignored and a warning is issued. > > That implies that home.create() will always go round trip. Isn't that > what we want to prevent for SLSB? Yeah I wanted to prevent that but given that (a) it's considerable added complexity (we'd need another proxy type) and (b) it's one edge case of EJB2-style stuff that hopefully is less-used, it doesn't really seem worth the trouble. >>>> 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. >> >> Except that "java:" belongs to EE, and this is very much non-spec. I >> don't think this type of functionality belongs in "java:" under any >> circumstances. > > In that case we should also refactor java:jboss. The reason I don't feel "java:jboss" applies the same way as "ejb:" is that (a) it is very unlikely to conflict, given that "jboss" is basically trademarked, and (b) it behaves very similarly to other "java:" namespaces. -- - DML _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev