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