sorry, was bounced again :(
---------- Forwarded message ----------
From: Romain Manni-Bucau <rmannibucau_at_gmail.com>
Date: 2015-02-10 9:30 GMT+01:00
Subject: Re: [javaee-spec users] [jsr366-experts] Re: global resources
To: jsr366-experts_at_javaee-spec.java.net
Hi
There is an alternative actually. If the resource is already bound by
either the container or an app then switch it for a contextual
resource.
Allows all apps to work even if not designed to work with the same
global resource - obviously the case if they all (re)define the same
resource.
Le 10 févr. 2015 02:33, "Jason Greene" <jason.greene_at_redhat.com> a écrit :
>
> > On Feb 9, 2015, at 6:19 PM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
> >
> > For Java EE implementors:
> >
> > Which approach do you implement?
> >
> > A. disallow
> > B. allow, creator owns
> > C. allow, no reference counting
> > D. allow, reference counting
> > E. other (explain)
>
> D
>
> >
> >
> >
> > For Java EE developers:
> >
> > Which approach do you expect?
> >
> > A. disallow
> > B. allow, creator owns
> > C. allow, no reference counting
> > D. allow, reference counting
> > E. other (explain)
> >
> >
> > For everyone:
> >
> > Which approach do you think the Java EE 7 spec requires?
> >
> > A. disallow
> > B. allow, creator owns
> > C. allow, no reference counting
> > D. allow, reference counting
> > E. other (explain)
> >
>
> IMO B and C do not make sense. I could understand why a vendor would report it as a conflict for multiple deployments though. D gives you consistent behavior which is why we chose it.
>
> >
> > Thanks.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>