[jboss-as7-dev] PART 3! of EJB Remote client design

Jaikiran Pai jpai at redhat.com
Thu Sep 22 04:14:53 EDT 2011


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


More information about the jboss-as7-dev mailing list