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