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
>
> 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
>>>>
>>>>
>>>>
>>>
>