Hi Jean-Louis,
The spec is clear now about #2 and #3 being invalid:
4.9.7Session Bean’s Business Interface
A bean class is permitted to have more than one interface. If a bean
class has more than one interface—excluding the interfaces listed
below—any business interface of the bean class must be explicitly
designated as a business interface of the bean by means of the Local or
Remote annotation on the bean class or interface or in the deployment
descriptor.
-marina
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
>
>
>