Le 28 août 2017 03:29, "Mark Struberg" <[email protected]> a écrit :
Well, theoretically a Map<CL, CDIProvider> might be more correct. But there is already a static (!) setter for it. So I fear there is not much we can do. Plus the CL trick is broken in most containers anyway for such low-level things. Think about EARs. You would only be able to set it for the main CL... Not really cause ear classloader is defined enough to have a lookup strategy. Also keep in mind setting it at runtime - from the app - leads to undefined behavior by design. The static setter is fine and doesnt mean it is backed by a singleton. It's also not practical to have different CDI containers which share the same API via a parent ClassLoader. If you have multiple CDI containers then they are fully separated - means including the API. Otherwise you are bound to a very specific version anyway. And thus it makes not much sense. Well it can - have exactly it but not with cdi - while you dont break the api. I know cdi was not that good on it - with its beansattributes for instance - but it should so it is a valid case. Also have to admit i was more thinking about a deployer where you choose your provider more than the spec version. LieGrue, strub > Am 27.08.2017 um 19:41 schrieb Jean-Baptiste Onofré <[email protected]>: > > Agree with Romain. > > Regards > JB > On Aug 27, 2017, at 17:48, Romain Manni-Bucau <[email protected]> wrote: > I don't like much this impl since it enforces a single CDI impl and flat classloader for the container but if really in the API we must, if just a leak from the javadoc we don't have to. > > > Romain Manni-Bucau > @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory > > 2017-08-27 18:31 GMT+02:00 John D. Ament <[email protected]>: > Hmmm so you're thinking we need to keep a map of classloader/CDIProvider pairs? > > > On Sun, Aug 27, 2017 at 12:16 PM Romain Manni-Bucau < [email protected]> wrote: > Doesn't break anything so +1 > > Now a few side note on it: > > 1. private static volatile CDI shouldn't be static IMO since it is broken in any container (including SE if not under a flat classloading of the cdi impl) > 2. i'm not sure how the patch changes much in practise (= maybe it does worth mentioning it in the class?) > 3. just realized we are not aligned on https://docs.jboss.org/cdi/ api/2.0/ "protected" behavior. This looks like an abuse of the javadoc "discovered API" but wonder if we want to be aligned on the spec or make the spec cleaned up > > If unclear: none of these point block a release but since we revisit this "to be enhanced" area I thought it was important to mention them > > > Romain Manni-Bucau > @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory > > 2017-08-27 14:22 GMT+02:00 John D. Ament <[email protected]>: > Hi > > I pushed up a small fix to the CDI spec. Would it make sense to cut a release of that? > > John > >
