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