Yes, we will need to emphasize that the new rule applies only to the
case when no views had been explicitly defined for a bean. I.e. in your
example, the old rule will apply and the bean would expose only one
view, Red.
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 {
> }
The above is actually a very good example, where Green and Blue do not
magically become a local view of the bean.
>
> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>