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

[David M. Lloyd]

On 09/22/2011 04:06 AM, Jaikiran Pai wrote:
> 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".

That's a legitimate problem IMO.  Let's talk about it in IRC today...

>> 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
>>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
- DML