On Jun 19, 2012, at 10:41 AM, Linda DeMichiel wrote:
> 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 {
> }
Right. The above case is what I intended with the "unless the user explicitly lists interfaces, then just the list would be considered."
So if you're implicit, you get all, if you explicitly list then you just get what you chose.
-David
> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>