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