On Thursday 22 September 2011 01:25 PM, Stuart Douglas wrote:
On 22/09/2011, at 5:34 PM, Jaikiran Pai wrote:
> Comments inline.
>
> On Thursday 22 September 2011 10:30 AM, David M. Lloyd wrote:
>> Client JNDI Revisited!
>> ----------------------
>>
>> Based on feedback here and in IRC, we're changing our approach to client
>> EJB thus:
>>
>> A new JNDI "scheme" will be introduced called "ejb". Lookups
into this
>> scheme following a naming convention will yield remote EJB proxies
>> directly. If the interface is not stateful, then the proxy is
>> immediately available without a server round-trip.
>>
>> The format for "ejb" scheme names is like this (square brackets are
not
>> literal; they indicate that the enclosed section is optional):
>>
>> "ejb:appname/modulename/[distinctname/]beanname!interface[?stateful]"
> The appname (assuming it's the .ear name that we talking of, like in the
> spec) should be optional too, isn't it? Although making appname optional
> might end up with non-deterministic jndi name like:
>
> ejb:a/b/c!interface
>
> and we wouldn't know whether:
>
> 1) "a" is appname and "b" is module name
> or
> 2) "a" is module name and "b" is distinct name
>
This problem is why we decided to make the app name required.
What would a user
specify as a value for appname when the application
isn't deployed as a .ear? If we want the appname to have a consistent
meaning, then I guess we could change the JNDI name syntax to:
"ejb:appname/modulename/beanname!interface[?stateful=(true|false)
[&distinctname=<blah>]]"
[] brackets indicate optional
() brackets indicate allowed values
<> indicates some value
-Jaikiran