5:43 p.m.
On 10/06/2011 08:33 AM, Jaikiran Pai wrote:
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:
[..example showing no-client exception..]
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.
I'm not really feeling like JNDI is a significant factor here. The JNDI
API is only there for the purpose of making remote injection nicer in
the server, and to provide a consistent experience for those who want to
stick with JNDI on the client.
I think we should shoot for these goals:
A) A standalone client should be able to look up a proxy from JNDI
without configuring a client context (this already works).
B) The standalone client should not have to remember to establish a
client context.
But I think we should still NOT automatically establish connections -
especially via JNDI, as this is a weird fit (given that the JNDI scheme
is not actually provided by Remoting, it's just being used as a
side-channel to get the invocation connection up).
To implement (B) we probably should just change EJBClientContext to use
ContextSelector, and just have a single global client context in the
standalone case by default. Users can switch to the thread-local
implementation if they want something more advanced. Then on the server
we can switch to something more sophisticated like TCCL or something,
maybe eliminate having to have *yet another* interceptor in this path.
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?
No because there's nobody to manage that connection. Which might be
fine in certain cases but overall it's just asking for resource leaks
IMO (there's no real lifecycle on JNDI contexts, nor on the EJB client
context). Also, only the most trivial authentication schemes will be
able to be utilized in this 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.
Yeah, that's also a good point. There are many other JNDI schemes out
in the wild and we should stop assuming we're the only ones.
--
- DML