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

[Jaikiran Pai]

On Thursday 22 September 2011 02:16 PM, Stuart Douglas wrote:
> Appname would just be the same as the module name in this case.
IMO, that would add to the confusion since we are adding newer meanings 
to appname. Furthermore, it could also result in picking up a wrong bean 
in cases like this:

deployments/
|
|--- a.ear
|      |--- a.jar (EJB module)
|      |      |--- <Foo bean>
|
|
|--- a.jar (EJB module)
|     |--- <Foo bean>

Server has a.ear containing a EJB module a.jar which contains Foo bean. 
The server also has a.jar EJB module containing Foo bean. Both Foo beans 
are unrelated in terms of implementation. If we say appname==modulename 
when .ear isn't present, then we'll end up with:

ejb:a/a/Foo!ViewClassName

and we won't be able to resolve the correct EJB. Of-course this could be 
"fixed" by adding a distinct name, but I don't think we should ask users 
to do that since the deployment structure already makes both deployments 
"distinct".

> Another option would be to allow
>
> ejb:app/module/c!interface
>
>   but assume that if the shorted form is used it always means appName/moduleName (rather than moduleName/distinctName). If you are using a distinct name
> you must specify appName/moduleName/distinctName, even if the appName and moduleName are the same.
>
I'm not too sure about this. My concern is that we might end up adding a 
bit more complexity than required for accommodating the "distinctname", 
which isn't really a common usecase. I would still prefer passing 
distinctname like a query param (?distinctname=blah). But if it doesn't 
look cleaner that way, then I would prefer a syntax which doesn't force 
a appname to be specified in the absence of a .ear. That would help us 
keep the meaning of "appname" consistent with other places where it is 
used (for example on server side in the jndi names of EJB).

-Jaikiran


> Stuart
>
> On 22/09/2011, at 6:14 PM, Jaikiran Pai wrote:
>
>> 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
>