8:33 a.m.
Now that we have some kind of stability on the EJB remote client API and
its implementation (ofcourse on our individual git branches), I was
looking around to see how easy/seamless the JNDI interaction from a
remote client is going to be from a user point of view. So I've got this
testcase (which runs as a remote client) which does lookup of a SLSB via
the ejb: jndi naming scheme that we have introduced:
@RunWith(Arquillian.class)
@RunAsClient
public class RemoteEJBJNDIAccessTestCase {
...
private Context initialContext;
@Before
public void beforeTest() throws Exception {
final Properties initCtxProps = new Properties();
initCtxProps.put(Context.URL_PKG_PREFIXES,
"org.jboss.ejb.client.naming");
this.initialContext = new InitialContext(initCtxProps);
}
... // trimmed some code which creates and deploys the deployment via
Arquillian @Deployment
...
@Test
public void testSLSBInvocation() throws Exception {
final String distinctName = "";
final EchoRemote echoRemote = (EchoRemote)
this.initialContext.lookup("ejb:" + APP_NAME + "/" + MODULE_NAME +
"/" +
distinctName + "/" + EchoBean.class.getSimpleName() + "!" +
EchoRemote.class.getName());
Assert.assertNotNull("Received a null proxy", echoRemote);
final String message = "Hello world from a really remote client
via a proxy from JNDI";
final String echo = echoRemote.echo(message);
Assert.assertEquals("Unexpected echo message", message, echo);
}
}
So the test first looks a up proxy using ejb:<...blah> and then invokes
on that bean proxy. The invocation on the proxy fails with:
java.lang.IllegalStateException: No EJB client context is set for this
thread
at
org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:150)
at
org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:77)
at $Proxy18.echo(Unknown Source)
at
org.jboss.as.testsuite.integration.ejb.remote.client.api.RemoteEJBJNDIAccessTestCase.testSLSBInvocation(RemoteEJBJNDIAccessTestCase.java:79)
That's expected because we haven't configured any EJBClientContext for
this invoking thread.
So the questions I had was:
1) Do we want the JNDI invocations to be really seamless (i.e. the above
code to functional)? I'm very much in favour of letting the users invoke
via JNDI without any explicit use of EJB client API in their code. I
don't see a point of using JNDI as well as EJB client API to get it to work.
2) My idea of making this work was to use the Context.PROVIDER_URL as
our remote receiver uri. So the jndi.properties or even the properties
passed to the InitialContext could contain (comma separated list)
something like remote://localhost:9999 (just an example) to point to the
remote EJB connector. The EJBNamingContext would then be smart enough to
first setup a (remoting) EJB receiver during context creation and then
setup a EJB client context on the invoking thread, when the proxy is
invoked (this would require the lookup to return a wrapper over the
invocation handler to intercept the calls on the proxy and just do a
EJBClientContext.setCurrent(...) before passing on the control to the
EJBInvocationHandler).
#2 is all impl details and actually has numerous issues with it:
a) It assumes that it would be OK to setup the remoting connection
ourselves and not mandate the user to provide one (we could actually
allow users to pass configurations for the connection). David has
mentioned that it wouldn't be a good idea creating the connection
ourselves. But that was in the context of pure native EJB client API
design. Does it make sense to somehow relax that require in this JNDI case?
b) The Context.PROVIDER_URL used in the jndi.properties or the
properties being passed to the InitialContext apply to the entire
context and aren't anything specific to EJB invocations. i.e. the user
could use that context to do lookup/invocations on non-EJB objects bound
to JNDI. I'm not sure how non-EJB JNDI lookup outside of the server VM
is being implemented/planned, so using that EJB specific(?) remoting
connector info (remote://<localhost:ejb-remote-connector-port>) in the
jndi.properties isn't probably a good idea.
So how do we go about this?
-Jaikiran