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