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 <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 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 <https://twitter.com/rmannibucau> | Blog >> <https://blog-rmannibucau.rhcloud.com> | Old Blog >> <http://rmannibucau.wordpress.com> | Github >> <https://github.com/rmannibucau> | LinkedIn >> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory >> <https://javaeefactory-rmannibucau.rhcloud.com> >> >> 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 >>> >> >>
