[ejb-spec users] [jsr345-experts] Re: Re: _at_Local interfaces
Thank you Stefan.
-marina
Stefan Heldt wrote:
> Marina,
>
> great work, especially the examples make things clear. There are just two minor typos in the headings of example 4 and 5. Should be only instead of ony.
>
> Regards
> Stefan!
>
> -----Ursprüngliche Nachricht-----
> Von: Marina Vatkina [mailto:marina.vatkina_at_oracle.com]
> Gesendet: Mittwoch, 4. Juli 2012 03:45
> Cc: jsr345-experts_at_ejb-spec.java.net
> Betreff: [ejb-spec users] [jsr345-experts] Re: @Local interfaces
>
> Experts,
>
> Please carefully review the new text of the section 4.9.7 Session Bean's Business Interface (the attachment has only 3 pages with the content of this section). Let me know if you can't access the pdf attachment and I'll post it on the spec site.
>
> thanks,
> -marina
>
> Marina Vatkina wrote:
>
>> Thanks to those who replied :).
>>
>> As there had been no objections, I'm adding these simplifications to
>> the spec (with all the notes that the simplified rules apply only in
>> default cases).
>>
>> If anybody feels a need to have a corresponding JIRA for this change,
>> please create one.
>>
>> thanks,
>> -marina
>>
>> Jean-Louis MONTEIRO wrote:
>>
>>> Hi,
>>>
>>> We consider that previous rules are still valid (can't imagine the
>>> opposite ATM), I mean as soon as the list is specified, we only
>>> publish the subset listed.
>>>
>>> So, I guess the vote only applies to what would defaults be in case
>>> nothing is specified.
>>>
>>> 1/ Nothing specified, the rule is the same as if only one interface
>>> is actually used. It's by default a "local" bean. Then, it becomes
>>> the same case as 2/
>>>
>>> 2/ Ok for me, the bean will be registered with 3 "local" interfaces
>>>
>>> 3/ Also ok for me, but the bean will be registered with 3 "remote"
>>> interfaces.
>>>
>>> Thanks Marina for the summary.
>>>
>>> Jean-Louis
>>>
>>>
>>> 2012/6/22 David Blevins <david.blevins_at_gmail.com
>>> <mailto:david.blevins_at_gmail.com>>
>>>
>>>
>>> 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>
>>> <mailto: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>
>>>
>>>>>>>>>>> <mailto: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>
>>>
>>>>>>>>>>> <mailto: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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>