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>
> 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>
>> To: jsr345-experts_at_ejb-spec.java.**net<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
>>
>>
>>