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