[jboss-as7-dev] EJB Remote client design

[Carlo de Wolf]

On 09/20/2011 03:15 PM, David M. Lloyd wrote:
> On 09/20/2011 04:33 AM, Jaikiran Pai wrote:
>> On Thursday 15 September 2011 09:20 AM, David M. Lloyd wrote:
>>> Client JNDI
>>> -----------
>>>
>>> Client JNDI is just a simple in-memory JNDI implementation.  We will not
>>> automatically bind anything to it at all, except in two possible cases:
>>> 1. A simple configuration file which describes what to bind, or 2. A
>>> configuration instructing a binding list to be fetched from somewhere.
>>>
>> I haven't found clear details around this in various JIRAs on what this
>> actually means to an end user. In previous version(s) of JBoss AS and
>> other application servers that are available, a remote client (for
>> example a standalone Java app) works as follows for remote EJB invocations:
>>
>> 1) The (remote) client setup adds some app server specific jars to the
>> runtime classpath of the client
>> 2) The code uses a app server specific or EJB3.1 spec standardised JNDI
>> names of EJBs to do a lookup using javax.naming.Context
>> 3) Invokes on the returned bean view proxy.
>>
>> In these above 3 steps, there is no other configuration or setup
>> required by the remote client to invoke on the bean using a JNDI name.
>>
>> So with the Client JNDI that we are proposing in AS7, does this mean,
>> that in AS7 we are _mandating_ an additional step/instruction to
>> configure/setup the JNDI on the client side so that the invocation via a
>> jndi name works? Or is it going to be transparent to the users without
>> any explicit configuration instruction?
>>
>> P.S: I am not talking about Java EE "application client" which is much
>> more than just remote invocation. Setting up a "application client"
>> always required additional configurations in all application servers
>> that I know of.
> Yesterday Jason and I chatted about another option: an "ejb:" JNDI
> scheme which simply directs to the API to construct any proxy.  It would
> work like this:
>
>
> context.lookup("ejb:theApp/theModule/theDistinctName/Stateful/theBean!org.interf.Blah");
>
> The name would be decomposed to actually create the proxy without
> contacting any server or requiring any configuration.  It could also
> coexist with a "java:" implementation meaning it could work on the
> server side too.

That's already working: 
https://github.com/jaikiran/jboss-ejb-client/blob/master/src/test/java/org/jboss/ejb/client/test/stateless/StatelessTestCase.java#L91 
except for the URL bit. But that is also an ObjectFactory.

It's a bit of a bummer how URL context factories are working by spec. It 
makes it hard to create a dynamic spec compliant URL context factory. 
But if we had a custom standalone JNDI implementation we could have 
dynamic URL context factories that refer to anything (/servers).

> Note that in your above example, you'd still have to tell it at least
> what server to talk to.

Carlo