[jboss-as7-dev] JNDI lookup and EJB invocation from a remote client

[David M. Lloyd]

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