Note that you will also need to define what happens when the bean has
both local and remote interfaces and/or when only some are explicitly listed.
For example, what happens with the following:
@Remote(Red.class)
@Stateless
public class Color implements Red, Green, Blue {
}
There is also this case:
@Local(Red.class)
@Stateless
public class Color implements Red, Green, Blue {
}
On 6/18/2012 2:44 PM, Marina Vatkina wrote:
> Experts,
>
> I'd like to get an agreement from the group before making this change.
>
> Please let me know if you agree that (assuming that no views had been explicitly defined):
>
> 1. @Stateless
> public class Color implements Red, Green, Blue {
> }
>
> Would *default* to the bean exposing 3 local business interface views
>
> 2. @Local
> @Stateless
> public class Color implements Red, Green, Blue {
> }
>
> Would mean that the bean exposes 3 *local* business interface views
>
> 3. @Remote
> @Stateless
> public class Color implements Red, Green, Blue {
> }
>
> Would mean that the bean exposes 3 *remote* business interface views
>
> thanks,
> -marina
>
>
> Carlo de Wolf wrote:
>> On 06/15/2012 09:40 PM, Marina Vatkina wrote:
>>> Carlo de Wolf wrote:
>>>>> 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 ...
>>>
>>> Agree.
>>>
>>> What about (assuming that no views had been explicitly defined)?
>>> @Remote
>>> @Stateless
>>> public class Color implements Red, Green, Blue {
>>>
>>> -marina
>>
>> If we extend the proposal to @Remote it would expose Red, Green and Blue as three remote business views.
>>
>> Carlo
>>>>
>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>