<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>I have an initial implementation of this at <a href="https://github.com/stuartwdouglas/jboss-ejb-client/commits/master/">https://github.com/stuartwdouglas/jboss-ejb-client/commits/master/</a> if anyone wants to give feedback. </div><div><br></div><div>Stuart</div><br><div><div>On 23/09/2011, at 12:50 AM, David M. Lloyd wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On 09/22/2011 08:59 AM, Carlo de Wolf wrote:<br><blockquote type="cite">On 09/22/2011 03:21 PM, David M. Lloyd wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">On 09/22/2011 03:52 AM, Carlo de Wolf wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On 09/22/2011 07:00 AM, David M. Lloyd wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Client JNDI Revisited!<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">----------------------<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Based on feedback here and in IRC, we're changing our approach to<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">client<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">EJB thus:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">A new JNDI "scheme" will be introduced called "ejb". Lookups into this<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">scheme following a naming convention will yield remote EJB proxies<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">directly. If the interface is not stateful, then the proxy is<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">immediately available without a server round-trip.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The format for "ejb" scheme names is like this (square brackets are not<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">literal; they indicate that the enclosed section is optional):<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">"ejb:appname/modulename/[distinctname/]beanname!interface[?stateful]"<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The "appname", "modulename", and "distinctname" are the identifying<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">names of the EJB deployment. "beanname" is the EJB-spec name of the<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">EJB. "interface" is the Java type name of the interface being returned.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The "?stateful" query parameter indicates that a session should be<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">initiated on lookup.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Since it is likely that users will erroneously use "?stateful" on a<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">stateful home interface (which is itself stateless), the lookup code<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">will detect whether the interface extends EJBHome before attempting to<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">initiate session, and if found will instead emit a warning.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Both a SLSB and a SFSB can have an EJBHome interface for their remote<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">home view. So I don't see how this can play a role in determining the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">session characteristic.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">In fact a call to a home view is always session-less, both for SLSB and<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">SFSB. The proxy returned by the create method represents the possible<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">session.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">That's what I said. EJBHome are always stateless. Therefore if<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">?stateful is given for an EJBHome, it is ignored and a warning is issued.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">That implies that home.create() will always go round trip. Isn't that<br></blockquote><blockquote type="cite">what we want to prevent for SLSB?<br></blockquote><br>Yeah I wanted to prevent that but given that (a) it's considerable added <br>complexity (we'd need another proxy type) and (b) it's one edge case of <br>EJB2-style stuff that hopefully is less-used, it doesn't really seem <br>worth the trouble.<br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">This gives us configuration-free JNDI. Also, it gives us a JNDI name<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">scheme we can use in server-side EJB references as a lookup-name which<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">can create dependency-free injections of remote EJBs that may not be<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">present on the current system. And it's also nice in that it doesn't<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">interfere with "java:" spec lookups at all.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">This should address all the issues raised with client JNDI thus far.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Binding the URL ObjectFactory to java:something would result in exactly<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the same functionality. We can still offer this choice to users.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Except that "java:" belongs to EE, and this is very much non-spec. I<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">don't think this type of functionality belongs in "java:" under any<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">circumstances.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">In that case we should also refactor java:jboss.<br></blockquote><br>The reason I don't feel "java:jboss" applies the same way as "ejb:" is <br>that (a) it is very unlikely to conflict, given that "jboss" is <br>basically trademarked, and (b) it behaves very similarly to other <br>"java:" namespaces.<br><br><br>-- <br>- DML<br>_______________________________________________<br>jboss-as7-dev mailing list<br><a href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/jboss-as7-dev<br></div></blockquote></div><br></body></html>