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