users@ejb-spec.java.net

[ejb-spec users] [jsr345-experts] Re: _at_Local interfaces

From: Marina Vatkina <marina.vatkina_at_oracle.com>
Date: Mon, 18 Jun 2012 14:44:46 -0700

Experts,

I'd like to get an agreement from the group before making this change.

Please let me know if you agree that (assuming that no views had been
explicitly defined):

1. @Stateless
     public class Color implements Red, Green, Blue {
     }

Would *default* to the bean exposing 3 local business interface views

2. @Local
    @Stateless
     public class Color implements Red, Green, Blue {
     }

Would mean that the bean exposes 3 *local* business interface views

3. @Remote
    @Stateless
     public class Color implements Red, Green, Blue {
     }

Would mean that the bean exposes 3 *remote* business interface views

thanks,
-marina


Carlo de Wolf wrote:
> On 06/15/2012 09:40 PM, Marina Vatkina wrote:
>> Carlo de Wolf wrote:
>>>> My personal opinion on @Local is that all interfaces directly
>>>> implemented in the class or parent classes should be implied
>>>> @Local unless the user explicitly lists interfaces, then just
>>>> the list would be considered.
>>>
>>> Suppose Red already has @Local, now all of a sudden we have three
>>> views instead of one.
>>>
>>> Probably the wording of the proposal is slightly off, it should
>>> probably start with: if no views have been explicitly defined ...
>>
>> Agree.
>>
>> What about (assuming that no views had been explicitly defined)?
>> @Remote
>> @Stateless
>> public class Color implements Red, Green, Blue {
>>
>> -marina
>
> If we extend the proposal to @Remote it would expose Red, Green and
> Blue as three remote business views.
>
> Carlo
>>>
>>> Carlo
>>>
>>> On 06/15/2012 08:13 PM, Marina Vatkina wrote:
>>>> Carlo,
>>>>
>>>> How does it apply to scenarios 2 and 3 that are currently
>>>> prohibited, and if allowed will mean more than one client view anyway?
>>>>
>>>> thanks,
>>>> -marina
>>>>
>>>> Carlo de Wolf wrote:
>>>>> The only problem I see is with 4.4.1:
>>>>>
>>>>> "In addition to the previous requirements, if the bean exposes
>>>>> only one of the applicable client interfaces
>>>>> (or, alternatively has only a no-interface view), the container
>>>>> registers an entry for that view with the
>>>>> following syntax:
>>>>>
>>>>> java:global[/<app-name>]/<module-name>/<bean-name>"
>>>>>
>>>>> Any proposal that changes the amount of views from one to many is
>>>>> not backwards compatible.
>>>>>
>>>>> Carlo
>>>>>
>>>>> On 06/15/2012 12:56 PM, Jean-Louis MONTEIRO wrote:
>>>>>> Hi Marina,
>>>>>>
>>>>>> Can't remember what is allowed or not in TomEE but I can
>>>>>> definitely recheck our validation rules.
>>>>>> But as David mentioned there are a couple of questions in the
>>>>>> mailing list and users seem to face issues when trying to port an
>>>>>> application across application servers.
>>>>>>
>>>>>> The more clear we can get the spec the better it is.
>>>>>> If we can provide sample, even better.
>>>>>>
>>>>>> Anyway, fully agree with Marina, #1 should not be allowed because
>>>>>> it too confusing regarding Local view beans.
>>>>>>
>>>>>> Would like to get feedback from JBoss guys as well.
>>>>>>
>>>>>> Jean-Louis
>>>>>>
>>>>>>
>>>>>> 2012/6/11 Marina Vatkina <marina.vatkina_at_oracle.com
>>>>>> <mailto:marina.vatkina_at_oracle.com>>
>>>>>>
>>>>>> David,
>>>>>>
>>>>>> In GlassFish (RI) verifier, if enabled, catches error condition
>>>>>> #1. #2 & #3 are not being caught. #4 follows the rules and Color
>>>>>> exposes only Red interface.
>>>>>>
>>>>>> I would say #1 is an error, because the bean is a LocalBean and
>>>>>> doesn't expose any other interface (not counting DD). #4 is
>>>>>> confusing for the developers, but I agree with Jeremy, changing
>>>>>> it would be backward incompatible.
>>>>>>
>>>>>> I don't see a problem with making #2 and #3 legal.
>>>>>>
>>>>>> What do others think?
>>>>>>
>>>>>> thanks,
>>>>>> -marina
>>>>>>
>>>>>> Jeremy Bauer wrote:
>>>>>>
>>>>>> David,
>>>>>>
>>>>>> WebSphere Application Server considers scenarios 1-3 error
>>>>>> conditions since, per rule, the server expects exactly one
>>>>>> interface on the implements clause. For scenario 4, only
>>>>>> the
>>>>>> "Red" business interface is provided.
>>>>>>
>>>>>> From a compatibility/issues perspective, scenario 4 is
>>>>>> troublesome. For vendors that do not currently provide
>>>>>> superclass interfaces as business interfaces, suddenly
>>>>>> making
>>>>>> them available could expose interfaces that the implementer
>>>>>> had no intention of exposing. At worst, this could pose a
>>>>>> security risk, especially in the case of exposing superclass
>>>>>> interfaces via @Remote. Otherwise, if only the bean
>>>>>> class is
>>>>>> considered, changing from a single-implements to an
>>>>>> all-implements does seem more intuitive and wouldn't pose an
>>>>>> upward compatibility concern.
>>>>>>
>>>>>> -Jeremy
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: David Blevins <david.blevins_at_gmail.com
>>>>>> <mailto:david.blevins_at_gmail.com>>
>>>>>> To: jsr345-experts_at_ejb-spec.java.net
>>>>>> <mailto:jsr345-experts_at_ejb-spec.java.net>
>>>>>> Date: 06/04/2012 04:30 PM
>>>>>> Subject: [jsr345-experts] @Local interfaces
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Users are reporting getting mixed results on various servers
>>>>>> with the following @Local usage.
>>>>>>
>>>>>> Scenario 1:
>>>>>>
>>>>>> @Local
>>>>>> @Stateless
>>>>>> public class Foo {
>>>>>> }
>>>>>>
>>>>>> Scenario 2:
>>>>>>
>>>>>> @Stateless
>>>>>> public class Color implements Red, Green, Blue {
>>>>>> }
>>>>>>
>>>>>> Scenario 3:
>>>>>>
>>>>>> @Local
>>>>>> @Stateless
>>>>>> public class Color implements Red, Green, Blue {
>>>>>> }
>>>>>>
>>>>>> Scenario 4:
>>>>>>
>>>>>> @Local
>>>>>> @Stateless
>>>>>> public class Color extends BaseColor implements Red {
>>>>>> }
>>>>>>
>>>>>> public class BaseColor implements Green, Blue {
>>>>>> }
>>>>>>
>>>>>>
>>>>>> Under the current rules, scenarios 1, 2 & 3 would be illegal
>>>>>> and scenario 4 would result a Color bean with exactly one
>>>>>> business local interface, Red.
>>>>>>
>>>>>> Some users are reporting all four working, sometimes will
>>>>>> all
>>>>>> three interfaces implied @Local. And, really, that is the
>>>>>> more intuitive approach.
>>>>>>
>>>>>> My personal opinion on @Local is that all interfaces
>>>>>> directly
>>>>>> implemented in the class or parent classes should be implied
>>>>>> @Local unless the user explicitly lists interfaces, then
>>>>>> just
>>>>>> the list would be considered.
>>>>>>
>>>>>> We might not be able to do that from a backwards
>>>>>> compatibility perspective, however two thoughts come to
>>>>>> mind:
>>>>>> it seems a compatibility issue already exists and is
>>>>>> affecting portability; the strict rules are perhaps too
>>>>>> pedantic and unintuitive.
>>>>>>
>>>>>> Immediately though, I don't think we want to take spec
>>>>>> action. At this stage I wonder if we could get people to
>>>>>> check their implementations and report back how these
>>>>>> scenarios are handled.
>>>>>>
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>