> 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.
Suppose Red already has @Local, now all of a sudden we have three views
instead of one.
Probably the wording of the proposal is slightly off, it should probably
start with: if no views have been explicitly defined ...
Carlo
On 06/15/2012 08:13 PM, Marina Vatkina wrote:
> Carlo,
>
> How does it apply to scenarios 2 and 3 that are currently prohibited,
> and if allowed will mean more than one client view anyway?
>
> thanks,
> -marina
>
> Carlo de Wolf wrote:
>> The only problem I see is with 4.4.1:
>>
>> "In addition to the previous requirements, if the bean exposes only
>> one of the applicable client interfaces
>> (or, alternatively has only a no-interface view), the container
>> registers an entry for that view with the
>> following syntax:
>>
>> java:global[/<app-name>]/<module-name>/<bean-name>"
>>
>> Any proposal that changes the amount of views from one to many is not
>> backwards compatible.
>>
>> Carlo
>>
>> On 06/15/2012 12:56 PM, 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
>>>
>>>
>>>
>>