4:06 a.m.
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