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