+1, that looks great and I like the example as well (easier to understand
the long sentences :D).
Jean-Louis
2012/7/5 Marina Vatkina <marina.vatkina_at_oracle.com>
> 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<marina.vatkina_at_oracle.com>]
>> Gesendet: Mittwoch, 4. Juli 2012 03:45
>> Cc: jsr345-experts_at_ejb-spec.java.**net <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 <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 <marina.vatkina_at_oracle.com>>
>>>> <mailto:marina.vatkina_at_oracle.**com <marina.vatkina_at_oracle.com><mailto:
>>>> marina.vatkina_at_oracle.**com <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 <david.blevins_at_gmail.com>>
>>>>
>>>>
>>>>> <mailto:david.blevins_at_gmail.**com <david.blevins_at_gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> <mailto:david.blevins_at_gmail.**com <david.blevins_at_gmail.com>>>>
>>>>
>>>>
>>>>> To: jsr345-experts_at_ejb-spec.java.**net<jsr345-experts_at_ejb-spec.java.net>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> <mailto:jsr345-experts_at_ejb-**spec.java.net<jsr345-experts_at_ejb-spec.java.net>
>>>> >
>>>>
>>>>
>>>>> <mailto:jsr345-experts_at_ejb-**spec.java.net<jsr345-experts_at_ejb-spec.java.net>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> <mailto:jsr345-experts_at_ejb-**spec.java.net<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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>
>>>