https://hibernate.atlassian.net/browse/HHH-11259 and friends are mainly about back porting the work I did on 6.0 for the ManagedBeanRegistry abstraction over dependency injection containers. We will ship support for CDI as well as non-managed beans (things we directly instantiate). Of course we'd ideally make it easy to plug in other DI containers such as Spring. So I wanted to discuss the configuration of this support. The first thing to consider is whether we want to support using multiple DI containers simultaneously. E.g. is it conceivable that an application might want to use both CDI and Spring simultaneously? I started building in support for that via a CompositeManagedBeanRegistry implementation, but stepping back I want to gauge whether that is "reasonable" before continuing down that path Assuming that we do want to support such "compositions" the next question is how we see this being configured. Clearly any time a CDI BeanManager is present during bootstrap we want to enable CDI ManagedBeanRegistry support. How would users indicate additional ManagedBeanRegistry impls be added to the CompositeManagedBeanRegistry? I have opinions about this, but I'd like to hear other's thoughts... Note that ManagedBeanRegistry is a service and is initiated via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it would be possible to completely redefine ManagedBeanRegistry support simply by replacing that initiator. A minor point... notice that the package name here is `org.hibernate.resource.cdi`, even though one of the goals here is to support non-CDI ManagedBeanRegistry impls. Do we want to use a different package name? Maybe `org.hibernate.resource.beans`? ``org.hibernate.resource.di`? ``org.hibernate.resource.injection`? Other suggestions? I'm actually ok with `org.hibernate.resource.cdi` - imo "cdi" conveys the proper intent. But if others feel strongly it should be something else, I am open to hearing what and why. _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Same here, compositions don't seem to be a reasonable use case. And even if users provide a custom bean registry, they could just implement their specific behavior for a few specific case, then retrieve another implementations on their own and delegate to it however they want. Overriding the service initiator looks like a very reasonable way to do that. Regarding the package, "org.hibernate.resource.beans" seems more appropriate to me, since CDI is not the only implementation we will get and we know it. Also, if I wanted to nitpick, injection is not really something the bean registry must provide. We could imagine a bean registry without any support for injection, after all, just providing "monolithic beans". It would still make sense with respect to your ManagedBeanRegistry API. Yoann Rodière Hibernate NoORM Team yoann(a)hibernate.org On 14 December 2017 at 08:01, Christian Beikov <christian.beikov(a)gmail.com > wrote: > I don't think someone is actually going to use more than a single DI > framework and even if they do, they will probably bridge one way or > another between the DI frameworks to be able to access beans from one in > the other. > > So I don't think we should do "compositions" since it's not a big deal > to integrate different DIs and is also IMO an edge case. I'd prefer the > package name `org.hibernate.resource.di` since CDI seems to be just one > of the possible "integrations". > > > Mit freundlichen Grüßen, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: > > https://hibernate.atlassian.net/browse/HHH-11259 and friends are mainly > > about back porting the work I did on 6.0 for the ManagedBeanRegistry > > abstraction over dependency injection containers. We will ship support > for > > CDI as well as non-managed beans (things we directly instantiate). Of > > course we'd ideally make it easy to plug in other DI containers such as > > Spring. So I wanted to discuss the configuration of this support. > > > > The first thing to consider is whether we want to support using multiple > DI > > containers simultaneously. E.g. is it conceivable that an application > > might want to use both CDI and Spring simultaneously? I started building > > in support for that via a CompositeManagedBeanRegistry implementation, > but > > stepping back I want to gauge whether that is "reasonable" before > > continuing down that path > > > > Assuming that we do want to support such "compositions" the next question > > is how we see this being configured. Clearly any time a CDI BeanManager > is > > present during bootstrap we want to enable CDI ManagedBeanRegistry > > support. How would users indicate additional ManagedBeanRegistry impls > be > > added to the CompositeManagedBeanRegistry? I have opinions about this, > but > > I'd like to hear other's thoughts... > > > > Note that ManagedBeanRegistry is a service and is initiated > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it > > would be possible to completely redefine ManagedBeanRegistry support > simply > > by replacing that initiator. > > > > A minor point... notice that the package name here is > > `org.hibernate.resource.cdi`, even though one of the goals here is to > > support non-CDI ManagedBeanRegistry impls. Do we want to use a different > > package name? Maybe `org.hibernate.resource.beans`? > > ``org.hibernate.resource.di`? ``org.hibernate.resource.injection`? > > Other suggestions? I'm actually ok with `org.hibernate.resource.cdi` - > imo > > "cdi" conveys the proper intent. But if others feel strongly it should > be > > something else, I am open to hearing what and why. > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Anyone know what happened to the 2.0 CDI artifact on Maven Central? It was there last week, but is no longer there... On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Thanks for the replies. So unless we hear otherwise from anyone else, I > will plan on supporting just one DI container. > > > > On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere <yoann(a)hibernate.org&gt; > wrote: > >> Same here, compositions don't seem to be a reasonable use case. And even >> if >> users provide a custom bean registry, they could just implement their >> specific behavior for a few specific case, then retrieve another >> implementations on their own and delegate to it however they want. >> Overriding the service initiator looks like a very reasonable way to do >> that. >> >> Regarding the package, "org.hibernate.resource.beans" seems more >> appropriate to me, since CDI is not the only implementation we will get >> and >> we know it. Also, if I wanted to nitpick, injection is not really >> something >> the bean registry must provide. We could imagine a bean registry without >> any support for injection, after all, just providing "monolithic beans". >> It >> would still make sense with respect to your ManagedBeanRegistry API. >> >> >> Yoann Rodière >> Hibernate NoORM Team >> yoann(a)hibernate.org >> >> On 14 December 2017 at 08:01, Christian Beikov < >> christian.beikov(a)gmail.com&gt; >> wrote: >> >> > I don't think someone is actually going to use more than a single DI >> > framework and even if they do, they will probably bridge one way or >> > another between the DI frameworks to be able to access beans from one >> in >> > the other. >> > >> > So I don't think we should do "compositions" since it's not a big deal >> > to integrate different DIs and is also IMO an edge case. I'd prefer the >> > package name `org.hibernate.resource.di` since CDI seems to be just one >> > of the possible "integrations". >> > >> > >> > Mit freundlichen Grüßen, >> > >> ------------------------------------------------------------------------ >> > *Christian Beikov* >> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >> > > https://hibernate.atlassian.net/browse/HHH-11259 and friends are >> mainly >> > > about back porting the work I did on 6.0 for the ManagedBeanRegistry >> > > abstraction over dependency injection containers. We will ship >> support >> > for >> > > CDI as well as non-managed beans (things we directly instantiate). >> Of >> > > course we'd ideally make it easy to plug in other DI containers such >> as >> > > Spring. So I wanted to discuss the configuration of this support. >> > > >> > > The first thing to consider is whether we want to support using >> multiple >> > DI >> > > containers simultaneously. E.g. is it conceivable that an >> application >> > > might want to use both CDI and Spring simultaneously? I started >> building >> > > in support for that via a CompositeManagedBeanRegistry >> implementation, >> > but >> > > stepping back I want to gauge whether that is "reasonable" before >> > > continuing down that path >> > > >> > > Assuming that we do want to support such "compositions" the next >> question >> > > is how we see this being configured. Clearly any time a CDI >> BeanManager >> > is >> > > present during bootstrap we want to enable CDI ManagedBeanRegistry >> > > support. How would users indicate additional ManagedBeanRegistry >> impls >> > be >> > > added to the CompositeManagedBeanRegistry? I have opinions about >> this, >> > but >> > > I'd like to hear other's thoughts... >> > > >> > > Note that ManagedBeanRegistry is a service and is initiated >> > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So >> it >> > > would be possible to completely redefine ManagedBeanRegistry support >> > simply >> > > by replacing that initiator. >> > > >> > > A minor point... notice that the package name here is >> > > `org.hibernate.resource.cdi`, even though one of the goals here is to >> > > support non-CDI ManagedBeanRegistry impls. Do we want to use a >> different >> > > package name? Maybe `org.hibernate.resource.beans`? >> > > ``org.hibernate.resource.di`? ``org.hibernate.resource.injection`? >> > > Other suggestions? I'm actually ok with >> `org.hibernate.resource.cdi` - >> > imo >> > > "cdi" conveys the proper intent. But if others feel strongly it >> should >> > be >> > > something else, I am open to hearing what and why. >> > > _______________________________________________ >> > > hibernate-dev mailing list >> > > hibernate-dev(a)lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >

Actually my fault. Apparently renaming the package was way too aggressive and renamed the artifact On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Ah, nm. They change the artifact name. Boo! > > On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> Anyone know what happened to the 2.0 CDI artifact on Maven Central? It >> was there last week, but is no longer there... >> >> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> Thanks for the replies. So unless we hear otherwise from anyone else, >>> I will plan on supporting just one DI container. >>> >>> >>> >>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere <yoann(a)hibernate.org&gt; >>> wrote: >>> >>>> Same here, compositions don't seem to be a reasonable use case. And >>>> even if >>>> users provide a custom bean registry, they could just implement their >>>> specific behavior for a few specific case, then retrieve another >>>> implementations on their own and delegate to it however they want. >>>> Overriding the service initiator looks like a very reasonable way to do >>>> that. >>>> >>>> Regarding the package, "org.hibernate.resource.beans" seems more >>>> appropriate to me, since CDI is not the only implementation we will >>>> get and >>>> we know it. Also, if I wanted to nitpick, injection is not really >>>> something >>>> the bean registry must provide. We could imagine a bean registry >>>> without >>>> any support for injection, after all, just providing "monolithic >>>> beans". It >>>> would still make sense with respect to your ManagedBeanRegistry API. >>>> >>>> >>>> Yoann Rodière >>>> Hibernate NoORM Team >>>> yoann(a)hibernate.org >>>> >>>> On 14 December 2017 at 08:01, Christian Beikov < >>>> christian.beikov(a)gmail.com&gt; >>>> wrote: >>>> >>>> > I don't think someone is actually going to use more than a single DI >>>> > framework and even if they do, they will probably bridge one way or >>>> > another between the DI frameworks to be able to access beans from >>>> one in >>>> > the other. >>>> > >>>> > So I don't think we should do "compositions" since it's not a big >>>> deal >>>> > to integrate different DIs and is also IMO an edge case. I'd prefer >>>> the >>>> > package name `org.hibernate.resource.di` since CDI seems to be just >>>> one >>>> > of the possible "integrations". >>>> > >>>> > >>>> > Mit freundlichen Grüßen, >>>> > >>>> ------------------------------------------------------------------------ >>>> > *Christian Beikov* >>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and friends are >>>> mainly >>>> > > about back porting the work I did on 6.0 for the >>>> ManagedBeanRegistry >>>> > > abstraction over dependency injection containers. We will ship >>>> support >>>> > for >>>> > > CDI as well as non-managed beans (things we directly >>>> instantiate). Of >>>> > > course we'd ideally make it easy to plug in other DI containers >>>> such as >>>> > > Spring. So I wanted to discuss the configuration of this support. >>>> > > >>>> > > The first thing to consider is whether we want to support using >>>> multiple >>>> > DI >>>> > > containers simultaneously. E.g. is it conceivable that an >>>> application >>>> > > might want to use both CDI and Spring simultaneously? I started >>>> building >>>> > > in support for that via a CompositeManagedBeanRegistry >>>> implementation, >>>> > but >>>> > > stepping back I want to gauge whether that is "reasonable" before >>>> > > continuing down that path >>>> > > >>>> > > Assuming that we do want to support such "compositions" the next >>>> question >>>> > > is how we see this being configured. Clearly any time a CDI >>>> BeanManager >>>> > is >>>> > > present during bootstrap we want to enable CDI ManagedBeanRegistry >>>> > > support. How would users indicate additional ManagedBeanRegistry >>>> impls >>>> > be >>>> > > added to the CompositeManagedBeanRegistry? I have opinions about >>>> this, >>>> > but >>>> > > I'd like to hear other's thoughts... >>>> > > >>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>> > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. >>>> So it >>>> > > would be possible to completely redefine ManagedBeanRegistry >>>> support >>>> > simply >>>> > > by replacing that initiator. >>>> > > >>>> > > A minor point... notice that the package name here is >>>> > > `org.hibernate.resource.cdi`, even though one of the goals here is >>>> to >>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to use a >>>> different >>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>> > > ``org.hibernate.resource.di`? >>>> ``org.hibernate.resource.injection`? >>>> > > Other suggestions? I'm actually ok with >>>> `org.hibernate.resource.cdi` - >>>> > imo >>>> > > "cdi" conveys the proper intent. But if others feel strongly it >>>> should >>>> > be >>>> > > something else, I am open to hearing what and why. >>>> > > _______________________________________________ >>>> > > hibernate-dev mailing list >>>> > > hibernate-dev(a)lists.jboss.org >>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >>>> > _______________________________________________ >>>> > hibernate-dev mailing list >>>> > hibernate-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>>

There are a lot of changes to digest here, but if anyone wanted to take a look at this so far... https://github.com/hibernate/hibernate-orm/commit/564ec55ca10c0d5d2afd732... On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Actually my fault. Apparently renaming the package was way too > aggressive and renamed the artifact > > On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> Ah, nm. They change the artifact name. Boo! >> >> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> Anyone know what happened to the 2.0 CDI artifact on Maven Central? It >>> was there last week, but is no longer there... >>> >>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> Thanks for the replies. So unless we hear otherwise from anyone else, >>>> I will plan on supporting just one DI container. >>>> >>>> >>>> >>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere <yoann(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> Same here, compositions don't seem to be a reasonable use case. And >>>>> even if >>>>> users provide a custom bean registry, they could just implement their >>>>> specific behavior for a few specific case, then retrieve another >>>>> implementations on their own and delegate to it however they want. >>>>> Overriding the service initiator looks like a very reasonable way to >>>>> do >>>>> that. >>>>> >>>>> Regarding the package, "org.hibernate.resource.beans" seems more >>>>> appropriate to me, since CDI is not the only implementation we will >>>>> get and >>>>> we know it. Also, if I wanted to nitpick, injection is not really >>>>> something >>>>> the bean registry must provide. We could imagine a bean registry >>>>> without >>>>> any support for injection, after all, just providing "monolithic >>>>> beans". It >>>>> would still make sense with respect to your ManagedBeanRegistry API. >>>>> >>>>> >>>>> Yoann Rodière >>>>> Hibernate NoORM Team >>>>> yoann(a)hibernate.org >>>>> >>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>> christian.beikov(a)gmail.com&gt; >>>>> wrote: >>>>> >>>>> > I don't think someone is actually going to use more than a single DI >>>>> > framework and even if they do, they will probably bridge one way or >>>>> > another between the DI frameworks to be able to access beans from >>>>> one in >>>>> > the other. >>>>> > >>>>> > So I don't think we should do "compositions" since it's not a big >>>>> deal >>>>> > to integrate different DIs and is also IMO an edge case. I'd prefer >>>>> the >>>>> > package name `org.hibernate.resource.di` since CDI seems to be just >>>>> one >>>>> > of the possible "integrations". >>>>> > >>>>> > >>>>> > Mit freundlichen Grüßen, >>>>> > >>>>> ------------------------------------------------------------------------ >>>>> > *Christian Beikov* >>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and friends are >>>>> mainly >>>>> > > about back porting the work I did on 6.0 for the >>>>> ManagedBeanRegistry >>>>> > > abstraction over dependency injection containers. We will ship >>>>> support >>>>> > for >>>>> > > CDI as well as non-managed beans (things we directly >>>>> instantiate). Of >>>>> > > course we'd ideally make it easy to plug in other DI containers >>>>> such as >>>>> > > Spring. So I wanted to discuss the configuration of this support. >>>>> > > >>>>> > > The first thing to consider is whether we want to support using >>>>> multiple >>>>> > DI >>>>> > > containers simultaneously. E.g. is it conceivable that an >>>>> application >>>>> > > might want to use both CDI and Spring simultaneously? I started >>>>> building >>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>> implementation, >>>>> > but >>>>> > > stepping back I want to gauge whether that is "reasonable" before >>>>> > > continuing down that path >>>>> > > >>>>> > > Assuming that we do want to support such "compositions" the next >>>>> question >>>>> > > is how we see this being configured. Clearly any time a CDI >>>>> BeanManager >>>>> > is >>>>> > > present during bootstrap we want to enable CDI ManagedBeanRegistry >>>>> > > support. How would users indicate additional ManagedBeanRegistry >>>>> impls >>>>> > be >>>>> > > added to the CompositeManagedBeanRegistry? I have opinions about >>>>> this, >>>>> > but >>>>> > > I'd like to hear other's thoughts... >>>>> > > >>>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>>> > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. >>>>> So it >>>>> > > would be possible to completely redefine ManagedBeanRegistry >>>>> support >>>>> > simply >>>>> > > by replacing that initiator. >>>>> > > >>>>> > > A minor point... notice that the package name here is >>>>> > > `org.hibernate.resource.cdi`, even though one of the goals here >>>>> is to >>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to use a >>>>> different >>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>> > > ``org.hibernate.resource.di`? >>>>> ``org.hibernate.resource.injection`? >>>>> > > Other suggestions? I'm actually ok with >>>>> `org.hibernate.resource.cdi` - >>>>> > imo >>>>> > > "cdi" conveys the proper intent. But if others feel strongly it >>>>> should >>>>> > be >>>>> > > something else, I am open to hearing what and why. >>>>> > > _______________________________________________ >>>>> > > hibernate-dev mailing list >>>>> > > hibernate-dev(a)lists.jboss.org >>>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> > >>>>> > _______________________________________________ >>>>> > hibernate-dev mailing list >>>>> > hibernate-dev(a)lists.jboss.org >>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> > >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>>

WRT to named beans, I asked Guillaume on HipChat what that is supposed to look like. IIRC he mentioned producers in Paris, but I found no straight-forward way to get from name+class to a bean. He may have answered, I just have not been on HipChat yet today... On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Its easier to cleanup > > On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> There are a lot of changes to digest here, but if anyone wanted to take >> a look at this so far... >> >> https://github.com/hibernate/hibernate-orm/commit/ >> 564ec55ca10c0d5d2afd73243dc0aa31759e8f5b >> >> >> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> Actually my fault. Apparently renaming the package was way too >>> aggressive and renamed the artifact >>> >>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> Ah, nm. They change the artifact name. Boo! >>>> >>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole <steve(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> Anyone know what happened to the 2.0 CDI artifact on Maven Central? >>>>> It was there last week, but is no longer there... >>>>> >>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole <steve(a)hibernate.org&gt; >>>>> wrote: >>>>> >>>>>> Thanks for the replies. So unless we hear otherwise from anyone >>>>>> else, I will plan on supporting just one DI container. >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere <yoann(a)hibernate.org&gt; >>>>>> wrote: >>>>>> >>>>>>> Same here, compositions don't seem to be a reasonable use case. And >>>>>>> even if >>>>>>> users provide a custom bean registry, they could just implement >>>>>>> their >>>>>>> specific behavior for a few specific case, then retrieve another >>>>>>> implementations on their own and delegate to it however they want. >>>>>>> Overriding the service initiator looks like a very reasonable way >>>>>>> to do >>>>>>> that. >>>>>>> >>>>>>> Regarding the package, "org.hibernate.resource.beans" seems more >>>>>>> appropriate to me, since CDI is not the only implementation we will >>>>>>> get and >>>>>>> we know it. Also, if I wanted to nitpick, injection is not really >>>>>>> something >>>>>>> the bean registry must provide. We could imagine a bean registry >>>>>>> without >>>>>>> any support for injection, after all, just providing "monolithic >>>>>>> beans". It >>>>>>> would still make sense with respect to your ManagedBeanRegistry API. >>>>>>> >>>>>>> >>>>>>> Yoann Rodière >>>>>>> Hibernate NoORM Team >>>>>>> yoann(a)hibernate.org >>>>>>> >>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>> christian.beikov(a)gmail.com&gt; >>>>>>> wrote: >>>>>>> >>>>>>> > I don't think someone is actually going to use more than a single >>>>>>> DI >>>>>>> > framework and even if they do, they will probably bridge one way >>>>>>> or >>>>>>> > another between the DI frameworks to be able to access beans from >>>>>>> one in >>>>>>> > the other. >>>>>>> > >>>>>>> > So I don't think we should do "compositions" since it's not a big >>>>>>> deal >>>>>>> > to integrate different DIs and is also IMO an edge case. I'd >>>>>>> prefer the >>>>>>> > package name `org.hibernate.resource.di` since CDI seems to be >>>>>>> just one >>>>>>> > of the possible "integrations". >>>>>>> > >>>>>>> > >>>>>>> > Mit freundlichen Grüßen, >>>>>>> > ------------------------------------------------------------ >>>>>>> ------------ >>>>>>> > *Christian Beikov* >>>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and friends >>>>>>> are mainly >>>>>>> > > about back porting the work I did on 6.0 for the >>>>>>> ManagedBeanRegistry >>>>>>> > > abstraction over dependency injection containers. We will ship >>>>>>> support >>>>>>> > for >>>>>>> > > CDI as well as non-managed beans (things we directly >>>>>>> instantiate). Of >>>>>>> > > course we'd ideally make it easy to plug in other DI containers >>>>>>> such as >>>>>>> > > Spring. So I wanted to discuss the configuration of this >>>>>>> support. >>>>>>> > > >>>>>>> > > The first thing to consider is whether we want to support using >>>>>>> multiple >>>>>>> > DI >>>>>>> > > containers simultaneously. E.g. is it conceivable that an >>>>>>> application >>>>>>> > > might want to use both CDI and Spring simultaneously? I >>>>>>> started building >>>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>>> implementation, >>>>>>> > but >>>>>>> > > stepping back I want to gauge whether that is "reasonable" >>>>>>> before >>>>>>> > > continuing down that path >>>>>>> > > >>>>>>> > > Assuming that we do want to support such "compositions" the >>>>>>> next question >>>>>>> > > is how we see this being configured. Clearly any time a CDI >>>>>>> BeanManager >>>>>>> > is >>>>>>> > > present during bootstrap we want to enable CDI >>>>>>> ManagedBeanRegistry >>>>>>> > > support. How would users indicate additional >>>>>>> ManagedBeanRegistry impls >>>>>>> > be >>>>>>> > > added to the CompositeManagedBeanRegistry? I have opinions >>>>>>> about this, >>>>>>> > but >>>>>>> > > I'd like to hear other's thoughts... >>>>>>> > > >>>>>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>>>>> > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. >>>>>>> So it >>>>>>> > > would be possible to completely redefine ManagedBeanRegistry >>>>>>> support >>>>>>> > simply >>>>>>> > > by replacing that initiator. >>>>>>> > > >>>>>>> > > A minor point... notice that the package name here is >>>>>>> > > `org.hibernate.resource.cdi`, even though one of the goals here >>>>>>> is to >>>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to use a >>>>>>> different >>>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>>> > > ``org.hibernate.resource.di`? ``org.hibernate.resource. >>>>>>> injection`? >>>>>>> > > Other suggestions? I'm actually ok with >>>>>>> `org.hibernate.resource.cdi` - >>>>>>> > imo >>>>>>> > > "cdi" conveys the proper intent. But if others feel strongly >>>>>>> it should >>>>>>> > be >>>>>>> > > something else, I am open to hearing what and why. >>>>>>> > > _______________________________________________ >>>>>>> > > hibernate-dev mailing list >>>>>>> > > hibernate-dev(a)lists.jboss.org >>>>>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > hibernate-dev mailing list >>>>>>> > hibernate-dev(a)lists.jboss.org >>>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>> > >>>>>>> _______________________________________________ >>>>>>> hibernate-dev mailing list >>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>>>

But your answer above does not answer my question ;) I still have no idea how to go from name+Class -> bean. On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere <yoann(a)hibernate.org&gt; wrote: > Yeah, it was 4AM in France when you asked :) I answered later on HipChat, > the answer is basically the one I gave in my email. > > Yoann Rodière > Hibernate NoORM Team > yoann(a)hibernate.org > > On 14 December 2017 at 14:38, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > >> WRT to named beans, I asked Guillaume on HipChat what that is supposed >> to look like. IIRC he mentioned producers in Paris, but I found no >> straight-forward way to get from name+class to a bean. >> >> He may have answered, I just have not been on HipChat yet today... >> >> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> Its easier to cleanup >>> >>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> There are a lot of changes to digest here, but if anyone wanted to >>>> take a look at this so far... >>>> >>>> >>>> https://github.com/hibernate/hibernate-orm/commit/564ec55ca10c0d5d2afd732... >>>> >>>> >>>> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole <steve(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> Actually my fault. Apparently renaming the package was way too >>>>> aggressive and renamed the artifact >>>>> >>>>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole <steve(a)hibernate.org&gt; >>>>> wrote: >>>>> >>>>>> Ah, nm. They change the artifact name. Boo! >>>>>> >>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole <steve(a)hibernate.org&gt; >>>>>> wrote: >>>>>> >>>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven >>>>>>> Central? It was there last week, but is no longer there... >>>>>>> >>>>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole <steve(a)hibernate.org&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> Thanks for the replies. So unless we hear otherwise from anyone >>>>>>>> else, I will plan on supporting just one DI container. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere <yoann(a)hibernate.org&gt; >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Same here, compositions don't seem to be a reasonable use case. >>>>>>>>> And even if >>>>>>>>> users provide a custom bean registry, they could just implement >>>>>>>>> their >>>>>>>>> specific behavior for a few specific case, then retrieve another >>>>>>>>> implementations on their own and delegate to it however they want. >>>>>>>>> Overriding the service initiator looks like a very reasonable way >>>>>>>>> to do >>>>>>>>> that. >>>>>>>>> >>>>>>>>> Regarding the package, "org.hibernate.resource.beans" seems more >>>>>>>>> appropriate to me, since CDI is not the only implementation we >>>>>>>>> will get and >>>>>>>>> we know it. Also, if I wanted to nitpick, injection is not really >>>>>>>>> something >>>>>>>>> the bean registry must provide. We could imagine a bean registry >>>>>>>>> without >>>>>>>>> any support for injection, after all, just providing "monolithic >>>>>>>>> beans". It >>>>>>>>> would still make sense with respect to your ManagedBeanRegistry >>>>>>>>> API. >>>>>>>>> >>>>>>>>> >>>>>>>>> Yoann Rodière >>>>>>>>> Hibernate NoORM Team >>>>>>>>> yoann(a)hibernate.org >>>>>>>>> >>>>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>>>> christian.beikov(a)gmail.com&gt; >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> > I don't think someone is actually going to use more than a >>>>>>>>> single DI >>>>>>>>> > framework and even if they do, they will probably bridge one >>>>>>>>> way or >>>>>>>>> > another between the DI frameworks to be able to access beans >>>>>>>>> from one in >>>>>>>>> > the other. >>>>>>>>> > >>>>>>>>> > So I don't think we should do "compositions" since it's not a >>>>>>>>> big deal >>>>>>>>> > to integrate different DIs and is also IMO an edge case. I'd >>>>>>>>> prefer the >>>>>>>>> > package name `org.hibernate.resource.di` since CDI seems to be >>>>>>>>> just one >>>>>>>>> > of the possible "integrations". >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Mit freundlichen Grüßen, >>>>>>>>> > >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> > *Christian Beikov* >>>>>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and friends >>>>>>>>> are mainly >>>>>>>>> > > about back porting the work I did on 6.0 for the >>>>>>>>> ManagedBeanRegistry >>>>>>>>> > > abstraction over dependency injection containers. We will >>>>>>>>> ship support >>>>>>>>> > for >>>>>>>>> > > CDI as well as non-managed beans (things we directly >>>>>>>>> instantiate). Of >>>>>>>>> > > course we'd ideally make it easy to plug in other DI >>>>>>>>> containers such as >>>>>>>>> > > Spring. So I wanted to discuss the configuration of this >>>>>>>>> support. >>>>>>>>> > > >>>>>>>>> > > The first thing to consider is whether we want to support >>>>>>>>> using multiple >>>>>>>>> > DI >>>>>>>>> > > containers simultaneously. E.g. is it conceivable that an >>>>>>>>> application >>>>>>>>> > > might want to use both CDI and Spring simultaneously? I >>>>>>>>> started building >>>>>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>>>>> implementation, >>>>>>>>> > but >>>>>>>>> > > stepping back I want to gauge whether that is "reasonable" >>>>>>>>> before >>>>>>>>> > > continuing down that path >>>>>>>>> > > >>>>>>>>> > > Assuming that we do want to support such "compositions" the >>>>>>>>> next question >>>>>>>>> > > is how we see this being configured. Clearly any time a CDI >>>>>>>>> BeanManager >>>>>>>>> > is >>>>>>>>> > > present during bootstrap we want to enable CDI >>>>>>>>> ManagedBeanRegistry >>>>>>>>> > > support. How would users indicate additional >>>>>>>>> ManagedBeanRegistry impls >>>>>>>>> > be >>>>>>>>> > > added to the CompositeManagedBeanRegistry? I have opinions >>>>>>>>> about this, >>>>>>>>> > but >>>>>>>>> > > I'd like to hear other's thoughts... >>>>>>>>> > > >>>>>>>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>>>>>>> > > via >>>>>>>>> org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it >>>>>>>>> > > would be possible to completely redefine ManagedBeanRegistry >>>>>>>>> support >>>>>>>>> > simply >>>>>>>>> > > by replacing that initiator. >>>>>>>>> > > >>>>>>>>> > > A minor point... notice that the package name here is >>>>>>>>> > > `org.hibernate.resource.cdi`, even though one of the goals >>>>>>>>> here is to >>>>>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to use >>>>>>>>> a different >>>>>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>>>>> > > ``org.hibernate.resource.di`? >>>>>>>>> ``org.hibernate.resource.injection`? >>>>>>>>> > > Other suggestions? I'm actually ok with >>>>>>>>> `org.hibernate.resource.cdi` - >>>>>>>>> > imo >>>>>>>>> > > "cdi" conveys the proper intent. But if others feel strongly >>>>>>>>> it should >>>>>>>>> > be >>>>>>>>> > > something else, I am open to hearing what and why. >>>>>>>>> > > _______________________________________________ >>>>>>>>> > > hibernate-dev mailing list >>>>>>>>> > > hibernate-dev(a)lists.jboss.org >>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>> > >>>>>>>>> > _______________________________________________ >>>>>>>>> > hibernate-dev mailing list >>>>>>>>> > hibernate-dev(a)lists.jboss.org >>>>>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>> > >>>>>>>>> _______________________________________________ >>>>>>>>> hibernate-dev mailing list >>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>> >>>>>>>> >

I'll be on HipChat later after I get back from taking my son and daughter to school. Maybe it is easier to discuss there. On Thu, Dec 14, 2017 at 7:44 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > But your answer above does not answer my question ;) > > I still have no idea how to go from name+Class -> bean. > > > On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere <yoann(a)hibernate.org&gt; > wrote: > >> Yeah, it was 4AM in France when you asked :) I answered later on >> HipChat, the answer is basically the one I gave in my email. >> >> Yoann Rodière >> Hibernate NoORM Team >> yoann(a)hibernate.org >> >> On 14 December 2017 at 14:38, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> WRT to named beans, I asked Guillaume on HipChat what that is supposed >>> to look like. IIRC he mentioned producers in Paris, but I found no >>> straight-forward way to get from name+class to a bean. >>> >>> He may have answered, I just have not been on HipChat yet today... >>> >>> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> Its easier to cleanup >>>> >>>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole <steve(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> There are a lot of changes to digest here, but if anyone wanted to >>>>> take a look at this so far... >>>>> >>>>> https://github.com/hibernate/hibernate-orm/commit/564ec55ca1 >>>>> 0c0d5d2afd73243dc0aa31759e8f5b >>>>> >>>>> >>>>> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole <steve(a)hibernate.org&gt; >>>>> wrote: >>>>> >>>>>> Actually my fault. Apparently renaming the package was way too >>>>>> aggressive and renamed the artifact >>>>>> >>>>>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole <steve(a)hibernate.org&gt; >>>>>> wrote: >>>>>> >>>>>>> Ah, nm. They change the artifact name. Boo! >>>>>>> >>>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole <steve(a)hibernate.org&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven >>>>>>>> Central? It was there last week, but is no longer there... >>>>>>>> >>>>>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole < >>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>> >>>>>>>>> Thanks for the replies. So unless we hear otherwise from anyone >>>>>>>>> else, I will plan on supporting just one DI container. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere < >>>>>>>>> yoann(a)hibernate.org&gt; wrote: >>>>>>>>> >>>>>>>>>> Same here, compositions don't seem to be a reasonable use case. >>>>>>>>>> And even if >>>>>>>>>> users provide a custom bean registry, they could just implement >>>>>>>>>> their >>>>>>>>>> specific behavior for a few specific case, then retrieve another >>>>>>>>>> implementations on their own and delegate to it however they >>>>>>>>>> want. >>>>>>>>>> Overriding the service initiator looks like a very reasonable >>>>>>>>>> way to do >>>>>>>>>> that. >>>>>>>>>> >>>>>>>>>> Regarding the package, "org.hibernate.resource.beans" seems more >>>>>>>>>> appropriate to me, since CDI is not the only implementation we >>>>>>>>>> will get and >>>>>>>>>> we know it. Also, if I wanted to nitpick, injection is not >>>>>>>>>> really something >>>>>>>>>> the bean registry must provide. We could imagine a bean registry >>>>>>>>>> without >>>>>>>>>> any support for injection, after all, just providing "monolithic >>>>>>>>>> beans". It >>>>>>>>>> would still make sense with respect to your ManagedBeanRegistry >>>>>>>>>> API. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yoann Rodière >>>>>>>>>> Hibernate NoORM Team >>>>>>>>>> yoann(a)hibernate.org >>>>>>>>>> >>>>>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>>>>> christian.beikov(a)gmail.com&gt; >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> > I don't think someone is actually going to use more than a >>>>>>>>>> single DI >>>>>>>>>> > framework and even if they do, they will probably bridge one >>>>>>>>>> way or >>>>>>>>>> > another between the DI frameworks to be able to access beans >>>>>>>>>> from one in >>>>>>>>>> > the other. >>>>>>>>>> > >>>>>>>>>> > So I don't think we should do "compositions" since it's not a >>>>>>>>>> big deal >>>>>>>>>> > to integrate different DIs and is also IMO an edge case. I'd >>>>>>>>>> prefer the >>>>>>>>>> > package name `org.hibernate.resource.di` since CDI seems to be >>>>>>>>>> just one >>>>>>>>>> > of the possible "integrations". >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > Mit freundlichen Grüßen, >>>>>>>>>> > ------------------------------------------------------------ >>>>>>>>>> ------------ >>>>>>>>>> > *Christian Beikov* >>>>>>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and >>>>>>>>>> friends are mainly >>>>>>>>>> > > about back porting the work I did on 6.0 for the >>>>>>>>>> ManagedBeanRegistry >>>>>>>>>> > > abstraction over dependency injection containers. We will >>>>>>>>>> ship support >>>>>>>>>> > for >>>>>>>>>> > > CDI as well as non-managed beans (things we directly >>>>>>>>>> instantiate). Of >>>>>>>>>> > > course we'd ideally make it easy to plug in other DI >>>>>>>>>> containers such as >>>>>>>>>> > > Spring. So I wanted to discuss the configuration of this >>>>>>>>>> support. >>>>>>>>>> > > >>>>>>>>>> > > The first thing to consider is whether we want to support >>>>>>>>>> using multiple >>>>>>>>>> > DI >>>>>>>>>> > > containers simultaneously. E.g. is it conceivable that an >>>>>>>>>> application >>>>>>>>>> > > might want to use both CDI and Spring simultaneously? I >>>>>>>>>> started building >>>>>>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>>>>>> implementation, >>>>>>>>>> > but >>>>>>>>>> > > stepping back I want to gauge whether that is "reasonable" >>>>>>>>>> before >>>>>>>>>> > > continuing down that path >>>>>>>>>> > > >>>>>>>>>> > > Assuming that we do want to support such "compositions" the >>>>>>>>>> next question >>>>>>>>>> > > is how we see this being configured. Clearly any time a CDI >>>>>>>>>> BeanManager >>>>>>>>>> > is >>>>>>>>>> > > present during bootstrap we want to enable CDI >>>>>>>>>> ManagedBeanRegistry >>>>>>>>>> > > support. How would users indicate additional >>>>>>>>>> ManagedBeanRegistry impls >>>>>>>>>> > be >>>>>>>>>> > > added to the CompositeManagedBeanRegistry? I have opinions >>>>>>>>>> about this, >>>>>>>>>> > but >>>>>>>>>> > > I'd like to hear other's thoughts... >>>>>>>>>> > > >>>>>>>>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>>>>>>>> > > via org.hibernate.resource.cdi.spi >>>>>>>>>> .ManagedBeanRegistryInitiator. So it >>>>>>>>>> > > would be possible to completely redefine ManagedBeanRegistry >>>>>>>>>> support >>>>>>>>>> > simply >>>>>>>>>> > > by replacing that initiator. >>>>>>>>>> > > >>>>>>>>>> > > A minor point... notice that the package name here is >>>>>>>>>> > > `org.hibernate.resource.cdi`, even though one of the goals >>>>>>>>>> here is to >>>>>>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to >>>>>>>>>> use a different >>>>>>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>>>>>> > > ``org.hibernate.resource.di`? >>>>>>>>>> ``org.hibernate.resource.injection`? >>>>>>>>>> > > Other suggestions? I'm actually ok with >>>>>>>>>> `org.hibernate.resource.cdi` - >>>>>>>>>> > imo >>>>>>>>>> > > "cdi" conveys the proper intent. But if others feel >>>>>>>>>> strongly it should >>>>>>>>>> > be >>>>>>>>>> > > something else, I am open to hearing what and why. >>>>>>>>>> > > _______________________________________________ >>>>>>>>>> > > hibernate-dev mailing list >>>>>>>>>> > > hibernate-dev(a)lists.jboss.org >>>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>> > >>>>>>>>>> > _______________________________________________ >>>>>>>>>> > hibernate-dev mailing list >>>>>>>>>> > hibernate-dev(a)lists.jboss.org >>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>> > >>>>>>>>>> _______________________________________________ >>>>>>>>>> hibernate-dev mailing list >>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>> >>>>>>>>> >>

Yoann, does this approach still need to do the injections (javax.enterprise.inject.spi.InjectionTarget)? On Thu, Dec 14, 2017 at 8:01 AM Yoann Rodiere <yoann(a)hibernate.org&gt; wrote: > Here is how it should work from what I understand (adapted from an > implementation in Search, which has slightly different requirements): > > static <T> T getBeanInstance(BeanManager beanManager, String beanName, > Class<T> contract) { > Set<Bean<?>> beans = beanManager.getBeans(contract, new NamedQualifier( > beanName)); > if ( beans.isEmpty() || beans.size() > 1 ) { > // TODO proper error messages > throw new IllegalArgumentException( "No matching beans or multiple > matching beans" ); > } > Bean<?> bean = beans.iterator().next(); > CreationalContext<T> creationalContext = > beanManager.createCreationalContext( bean ); > return contract.cast( beanManager.getReference( bean, contract, > creationalContext ) ); > } > > With NamedQualifier being the implementation I gave before. > > Sure, let's talk about it later on HipChat. Especially the caching thing, > it's really a blocker for Search. > > I'll be online to travel in about 3 hours, though. > > > Yoann Rodière > Hibernate NoORM Team > yoann(a)hibernate.org > > On 14 December 2017 at 14:46, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > >> I'll be on HipChat later after I get back from taking my son and >> daughter to school. Maybe it is easier to discuss there. >> >> On Thu, Dec 14, 2017 at 7:44 AM Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> But your answer above does not answer my question ;) >>> >>> I still have no idea how to go from name+Class -> bean. >>> >>> >>> On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere <yoann(a)hibernate.org&gt; >>> wrote: >>> >>>> Yeah, it was 4AM in France when you asked :) I answered later on >>>> HipChat, the answer is basically the one I gave in my email. >>>> >>>> Yoann Rodière >>>> Hibernate NoORM Team >>>> yoann(a)hibernate.org >>>> >>>> On 14 December 2017 at 14:38, Steve Ebersole <steve(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> WRT to named beans, I asked Guillaume on HipChat what that is >>>>> supposed to look like. IIRC he mentioned producers in Paris, but I found >>>>> no straight-forward way to get from name+class to a bean. >>>>> >>>>> He may have answered, I just have not been on HipChat yet today... >>>>> >>>>> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole <steve(a)hibernate.org&gt; >>>>> wrote: >>>>> >>>>>> Its easier to cleanup >>>>>> >>>>>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole <steve(a)hibernate.org&gt; >>>>>> wrote: >>>>>> >>>>>>> There are a lot of changes to digest here, but if anyone wanted to >>>>>>> take a look at this so far... >>>>>>> >>>>>>> >>>>>>> https://github.com/hibernate/hibernate-orm/commit/564ec55ca10c0d5d2afd732... >>>>>>> >>>>>>> >>>>>>> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole <steve(a)hibernate.org&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> Actually my fault. Apparently renaming the package was way too >>>>>>>> aggressive and renamed the artifact >>>>>>>> >>>>>>>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole < >>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>> >>>>>>>>> Ah, nm. They change the artifact name. Boo! >>>>>>>>> >>>>>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole < >>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>> >>>>>>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven >>>>>>>>>> Central? It was there last week, but is no longer there... >>>>>>>>>> >>>>>>>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole < >>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>>> >>>>>>>>>>> Thanks for the replies. So unless we hear otherwise from >>>>>>>>>>> anyone else, I will plan on supporting just one DI container. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere < >>>>>>>>>>> yoann(a)hibernate.org&gt; wrote: >>>>>>>>>>> >>>>>>>>>>>> Same here, compositions don't seem to be a reasonable use >>>>>>>>>>>> case. And even if >>>>>>>>>>>> users provide a custom bean registry, they could just >>>>>>>>>>>> implement their >>>>>>>>>>>> specific behavior for a few specific case, then retrieve >>>>>>>>>>>> another >>>>>>>>>>>> implementations on their own and delegate to it however they >>>>>>>>>>>> want. >>>>>>>>>>>> Overriding the service initiator looks like a very reasonable >>>>>>>>>>>> way to do >>>>>>>>>>>> that. >>>>>>>>>>>> >>>>>>>>>>>> Regarding the package, "org.hibernate.resource.beans" seems >>>>>>>>>>>> more >>>>>>>>>>>> appropriate to me, since CDI is not the only implementation we >>>>>>>>>>>> will get and >>>>>>>>>>>> we know it. Also, if I wanted to nitpick, injection is not >>>>>>>>>>>> really something >>>>>>>>>>>> the bean registry must provide. We could imagine a bean >>>>>>>>>>>> registry without >>>>>>>>>>>> any support for injection, after all, just providing >>>>>>>>>>>> "monolithic beans". It >>>>>>>>>>>> would still make sense with respect to your >>>>>>>>>>>> ManagedBeanRegistry API. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Yoann Rodière >>>>>>>>>>>> Hibernate NoORM Team >>>>>>>>>>>> yoann(a)hibernate.org >>>>>>>>>>>> >>>>>>>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>>>>>>> christian.beikov(a)gmail.com&gt; >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> > I don't think someone is actually going to use more than a >>>>>>>>>>>> single DI >>>>>>>>>>>> > framework and even if they do, they will probably bridge one >>>>>>>>>>>> way or >>>>>>>>>>>> > another between the DI frameworks to be able to access beans >>>>>>>>>>>> from one in >>>>>>>>>>>> > the other. >>>>>>>>>>>> > >>>>>>>>>>>> > So I don't think we should do "compositions" since it's not >>>>>>>>>>>> a big deal >>>>>>>>>>>> > to integrate different DIs and is also IMO an edge case. I'd >>>>>>>>>>>> prefer the >>>>>>>>>>>> > package name `org.hibernate.resource.di` since CDI seems to >>>>>>>>>>>> be just one >>>>>>>>>>>> > of the possible "integrations". >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > Mit freundlichen Grüßen, >>>>>>>>>>>> > >>>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>>> > *Christian Beikov* >>>>>>>>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>>>>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and >>>>>>>>>>>> friends are mainly >>>>>>>>>>>> > > about back porting the work I did on 6.0 for the >>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>> > > abstraction over dependency injection containers. We will >>>>>>>>>>>> ship support >>>>>>>>>>>> > for >>>>>>>>>>>> > > CDI as well as non-managed beans (things we directly >>>>>>>>>>>> instantiate). Of >>>>>>>>>>>> > > course we'd ideally make it easy to plug in other DI >>>>>>>>>>>> containers such as >>>>>>>>>>>> > > Spring. So I wanted to discuss the configuration of this >>>>>>>>>>>> support. >>>>>>>>>>>> > > >>>>>>>>>>>> > > The first thing to consider is whether we want to support >>>>>>>>>>>> using multiple >>>>>>>>>>>> > DI >>>>>>>>>>>> > > containers simultaneously. E.g. is it conceivable that an >>>>>>>>>>>> application >>>>>>>>>>>> > > might want to use both CDI and Spring simultaneously? I >>>>>>>>>>>> started building >>>>>>>>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>>>>>>>> implementation, >>>>>>>>>>>> > but >>>>>>>>>>>> > > stepping back I want to gauge whether that is "reasonable" >>>>>>>>>>>> before >>>>>>>>>>>> > > continuing down that path >>>>>>>>>>>> > > >>>>>>>>>>>> > > Assuming that we do want to support such "compositions" >>>>>>>>>>>> the next question >>>>>>>>>>>> > > is how we see this being configured. Clearly any time a >>>>>>>>>>>> CDI BeanManager >>>>>>>>>>>> > is >>>>>>>>>>>> > > present during bootstrap we want to enable CDI >>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>> > > support. How would users indicate additional >>>>>>>>>>>> ManagedBeanRegistry impls >>>>>>>>>>>> > be >>>>>>>>>>>> > > added to the CompositeManagedBeanRegistry? I have >>>>>>>>>>>> opinions about this, >>>>>>>>>>>> > but >>>>>>>>>>>> > > I'd like to hear other's thoughts... >>>>>>>>>>>> > > >>>>>>>>>>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>>>>>>>>>> > > via >>>>>>>>>>>> org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it >>>>>>>>>>>> > > would be possible to completely redefine >>>>>>>>>>>> ManagedBeanRegistry support >>>>>>>>>>>> > simply >>>>>>>>>>>> > > by replacing that initiator. >>>>>>>>>>>> > > >>>>>>>>>>>> > > A minor point... notice that the package name here is >>>>>>>>>>>> > > `org.hibernate.resource.cdi`, even though one of the goals >>>>>>>>>>>> here is to >>>>>>>>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to >>>>>>>>>>>> use a different >>>>>>>>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>>>>>>>> > > ``org.hibernate.resource.di`? >>>>>>>>>>>> ``org.hibernate.resource.injection`? >>>>>>>>>>>> > > Other suggestions? I'm actually ok with >>>>>>>>>>>> `org.hibernate.resource.cdi` - >>>>>>>>>>>> > imo >>>>>>>>>>>> > > "cdi" conveys the proper intent. But if others feel >>>>>>>>>>>> strongly it should >>>>>>>>>>>> > be >>>>>>>>>>>> > > something else, I am open to hearing what and why. >>>>>>>>>>>> > > _______________________________________________ >>>>>>>>>>>> > > hibernate-dev mailing list >>>>>>>>>>>> > > hibernate-dev(a)lists.jboss.org >>>>>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>> > >>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>> > hibernate-dev mailing list >>>>>>>>>>>> > hibernate-dev(a)lists.jboss.org >>>>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>> > >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>> >>>>>>>>>>> >>>> >

Hi, Following our conversations on HipChat and the various changes you implemented (thanks!), I tested the current implementation. There were a few issues, but I managed to fix them and make all the tests in Hibernate Search pass. Here is a PR with the fixes: https://github.com/hibernate/hibernate-orm/pull/2092 Yoann Rodière Hibernate NoORM Team yoann(a)hibernate.org On 14 December 2017 at 18:42, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Here is the commit with initial support for named CDI beans and support > for bypassing registry caching of ManagedBeans : > https://github.com/hibernate/hibernate-orm/commit/ddc1f03abc675a27ed025b8... > > There is still a question of whether named beans support needs to do > the javax.enterprise.inject.spi.InjectionTarget stuff > > Christian, I ended up going to "beans" as the package name because this > supports non-CDI environments (direct instantiation) too. Not overly a fan > of "beans" (overloaded term) but it was a lesser of evils. > > On Thu, Dec 14, 2017 at 10:57 AM Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> Yoann, does this approach still need to do the injections >> (javax.enterprise.inject.spi.InjectionTarget)? >> >> >> On Thu, Dec 14, 2017 at 8:01 AM Yoann Rodiere <yoann(a)hibernate.org&gt; >> wrote: >> >>> Here is how it should work from what I understand (adapted from an >>> implementation in Search, which has slightly different requirements): >>> >>> static <T> T getBeanInstance(BeanManager beanManager, String beanName, >>> Class<T> contract) { >>> Set<Bean<?>> beans = beanManager.getBeans(contract, new NamedQualifier( >>> beanName)); >>> if ( beans.isEmpty() || beans.size() > 1 ) { >>> // TODO proper error messages >>> throw new IllegalArgumentException( "No matching beans or multiple >>> matching beans" ); >>> } >>> Bean<?> bean = beans.iterator().next(); >>> CreationalContext<T> creationalContext = >>> beanManager.createCreationalContext( bean ); >>> return contract.cast( beanManager.getReference( bean, contract, >>> creationalContext ) ); >>> } >>> >>> With NamedQualifier being the implementation I gave before. >>> >>> Sure, let's talk about it later on HipChat. Especially the caching >>> thing, it's really a blocker for Search. >>> >>> I'll be online to travel in about 3 hours, though. >>> >>> >>> Yoann Rodière >>> Hibernate NoORM Team >>> yoann(a)hibernate.org >>> >>> On 14 December 2017 at 14:46, Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> I'll be on HipChat later after I get back from taking my son and >>>> daughter to school. Maybe it is easier to discuss there. >>>> >>>> On Thu, Dec 14, 2017 at 7:44 AM Steve Ebersole <steve(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> But your answer above does not answer my question ;) >>>>> >>>>> I still have no idea how to go from name+Class -> bean. >>>>> >>>>> >>>>> On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere <yoann(a)hibernate.org&gt; >>>>> wrote: >>>>> >>>>>> Yeah, it was 4AM in France when you asked :) I answered later on >>>>>> HipChat, the answer is basically the one I gave in my email. >>>>>> >>>>>> Yoann Rodière >>>>>> Hibernate NoORM Team >>>>>> yoann(a)hibernate.org >>>>>> >>>>>> On 14 December 2017 at 14:38, Steve Ebersole <steve(a)hibernate.org&gt; >>>>>> wrote: >>>>>> >>>>>>> WRT to named beans, I asked Guillaume on HipChat what that is >>>>>>> supposed to look like. IIRC he mentioned producers in Paris, but I found >>>>>>> no straight-forward way to get from name+class to a bean. >>>>>>> >>>>>>> He may have answered, I just have not been on HipChat yet today... >>>>>>> >>>>>>> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole <steve(a)hibernate.org&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> Its easier to cleanup >>>>>>>> >>>>>>>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole < >>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>> >>>>>>>>> There are a lot of changes to digest here, but if anyone wanted >>>>>>>>> to take a look at this so far... >>>>>>>>> >>>>>>>>> >>>>>>>>> https://github.com/hibernate/hibernate-orm/commit/564ec55ca10c0d5d2afd732... >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole < >>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>> >>>>>>>>>> Actually my fault. Apparently renaming the package was way too >>>>>>>>>> aggressive and renamed the artifact >>>>>>>>>> >>>>>>>>>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole < >>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>>> >>>>>>>>>>> Ah, nm. They change the artifact name. Boo! >>>>>>>>>>> >>>>>>>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole < >>>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>>>> >>>>>>>>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven >>>>>>>>>>>> Central? It was there last week, but is no longer there... >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole < >>>>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Thanks for the replies. So unless we hear otherwise from >>>>>>>>>>>>> anyone else, I will plan on supporting just one DI container. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere < >>>>>>>>>>>>> yoann(a)hibernate.org&gt; wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Same here, compositions don't seem to be a reasonable use >>>>>>>>>>>>>> case. And even if >>>>>>>>>>>>>> users provide a custom bean registry, they could just >>>>>>>>>>>>>> implement their >>>>>>>>>>>>>> specific behavior for a few specific case, then retrieve >>>>>>>>>>>>>> another >>>>>>>>>>>>>> implementations on their own and delegate to it however they >>>>>>>>>>>>>> want. >>>>>>>>>>>>>> Overriding the service initiator looks like a very >>>>>>>>>>>>>> reasonable way to do >>>>>>>>>>>>>> that. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regarding the package, "org.hibernate.resource.beans" seems >>>>>>>>>>>>>> more >>>>>>>>>>>>>> appropriate to me, since CDI is not the only implementation >>>>>>>>>>>>>> we will get and >>>>>>>>>>>>>> we know it. Also, if I wanted to nitpick, injection is not >>>>>>>>>>>>>> really something >>>>>>>>>>>>>> the bean registry must provide. We could imagine a bean >>>>>>>>>>>>>> registry without >>>>>>>>>>>>>> any support for injection, after all, just providing >>>>>>>>>>>>>> "monolithic beans". It >>>>>>>>>>>>>> would still make sense with respect to your >>>>>>>>>>>>>> ManagedBeanRegistry API. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yoann Rodière >>>>>>>>>>>>>> Hibernate NoORM Team >>>>>>>>>>>>>> yoann(a)hibernate.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>>>>>>>>> christian.beikov(a)gmail.com&gt; >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> > I don't think someone is actually going to use more than a >>>>>>>>>>>>>> single DI >>>>>>>>>>>>>> > framework and even if they do, they will probably bridge >>>>>>>>>>>>>> one way or >>>>>>>>>>>>>> > another between the DI frameworks to be able to access >>>>>>>>>>>>>> beans from one in >>>>>>>>>>>>>> > the other. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > So I don't think we should do "compositions" since it's >>>>>>>>>>>>>> not a big deal >>>>>>>>>>>>>> > to integrate different DIs and is also IMO an edge case. >>>>>>>>>>>>>> I'd prefer the >>>>>>>>>>>>>> > package name `org.hibernate.resource.di` since CDI seems >>>>>>>>>>>>>> to be just one >>>>>>>>>>>>>> > of the possible "integrations". >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Mit freundlichen Grüßen, >>>>>>>>>>>>>> > >>>>>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>>>>> > *Christian Beikov* >>>>>>>>>>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>>>>>>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and >>>>>>>>>>>>>> friends are mainly >>>>>>>>>>>>>> > > about back porting the work I did on 6.0 for the >>>>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>>>> > > abstraction over dependency injection containers. We >>>>>>>>>>>>>> will ship support >>>>>>>>>>>>>> > for >>>>>>>>>>>>>> > > CDI as well as non-managed beans (things we directly >>>>>>>>>>>>>> instantiate). Of >>>>>>>>>>>>>> > > course we'd ideally make it easy to plug in other DI >>>>>>>>>>>>>> containers such as >>>>>>>>>>>>>> > > Spring. So I wanted to discuss the configuration of >>>>>>>>>>>>>> this support. >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > The first thing to consider is whether we want to >>>>>>>>>>>>>> support using multiple >>>>>>>>>>>>>> > DI >>>>>>>>>>>>>> > > containers simultaneously. E.g. is it conceivable that >>>>>>>>>>>>>> an application >>>>>>>>>>>>>> > > might want to use both CDI and Spring simultaneously? I >>>>>>>>>>>>>> started building >>>>>>>>>>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>>>>>>>>>> implementation, >>>>>>>>>>>>>> > but >>>>>>>>>>>>>> > > stepping back I want to gauge whether that is >>>>>>>>>>>>>> "reasonable" before >>>>>>>>>>>>>> > > continuing down that path >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > Assuming that we do want to support such "compositions" >>>>>>>>>>>>>> the next question >>>>>>>>>>>>>> > > is how we see this being configured. Clearly any time a >>>>>>>>>>>>>> CDI BeanManager >>>>>>>>>>>>>> > is >>>>>>>>>>>>>> > > present during bootstrap we want to enable CDI >>>>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>>>> > > support. How would users indicate additional >>>>>>>>>>>>>> ManagedBeanRegistry impls >>>>>>>>>>>>>> > be >>>>>>>>>>>>>> > > added to the CompositeManagedBeanRegistry? I have >>>>>>>>>>>>>> opinions about this, >>>>>>>>>>>>>> > but >>>>>>>>>>>>>> > > I'd like to hear other's thoughts... >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > Note that ManagedBeanRegistry is a service and is >>>>>>>>>>>>>> initiated >>>>>>>>>>>>>> > > via >>>>>>>>>>>>>> org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it >>>>>>>>>>>>>> > > would be possible to completely redefine >>>>>>>>>>>>>> ManagedBeanRegistry support >>>>>>>>>>>>>> > simply >>>>>>>>>>>>>> > > by replacing that initiator. >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > A minor point... notice that the package name here is >>>>>>>>>>>>>> > > `org.hibernate.resource.cdi`, even though one of the >>>>>>>>>>>>>> goals here is to >>>>>>>>>>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want >>>>>>>>>>>>>> to use a different >>>>>>>>>>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>>>>>>>>>> > > ``org.hibernate.resource.di`? >>>>>>>>>>>>>> ``org.hibernate.resource.injection`? >>>>>>>>>>>>>> > > Other suggestions? I'm actually ok with >>>>>>>>>>>>>> `org.hibernate.resource.cdi` - >>>>>>>>>>>>>> > imo >>>>>>>>>>>>>> > > "cdi" conveys the proper intent. But if others feel >>>>>>>>>>>>>> strongly it should >>>>>>>>>>>>>> > be >>>>>>>>>>>>>> > > something else, I am open to hearing what and why. >>>>>>>>>>>>>> > > _______________________________________________ >>>>>>>>>>>>>> > > hibernate-dev mailing list >>>>>>>>>>>>>> > > hibernate-dev(a)lists.jboss.org >>>>>>>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>>>> > hibernate-dev mailing list >>>>>>>>>>>>>> > hibernate-dev(a)lists.jboss.org >>>>>>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>>>> > >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> >>>

> However, I do think that there is still a need to expand the proposal Scott and I want to make to the CDI spec wrt something like our ExtendedBeanManager to also account for the shutdown phase +1, I sent an email about just that on the mailing list. There are some drawbacks to this approach though, and Sanne suggested deeper integration into CDI would be a more future-proof path. The subject of this thread was "CDI integration in Hibernate ORM and the Application scope". Yoann Rodière Hibernate NoORM Team yoann(a)hibernate.org On 21 December 2017 at 16:36, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Awesome! Glad it worked out. > > However, I do think that there is still a need to expand the proposal > Scott and I want to make to the CDI spec wrt something like our > ExtendedBeanManager to also account for the shutdown phase. In addition to > knowing when the BeanManager is ready to use, it would be nice to know when > the BeanManager is ready to shutdown (a before shutdown hook). At that > point we could begin cleaning up our CreationalContext, etc refs. > > Scott, do you already have enough insight into that in WildFly for us to > go ahead and do that in our integration today? > > On Thu, Dec 21, 2017, 1:53 AM Yoann Rodiere <yoann(a)hibernate.org&gt; wrote: > >> Hi, >> >> Following our conversations on HipChat and the various changes you >> implemented (thanks!), I tested the current implementation. There were a >> few issues, but I managed to fix them and make all the tests in Hibernate >> Search pass. >> Here is a PR with the fixes: >> https://github.com/hibernate/hibernate-orm/pull/2092 >> >> Yoann Rodière >> Hibernate NoORM Team >> yoann(a)hibernate.org >> >> On 14 December 2017 at 18:42, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> Here is the commit with initial support for named CDI beans and support >>> for bypassing registry caching of ManagedBeans : >>> https://github.com/hibernate/hibernate-orm/commit/ddc1f03abc675a27ed025b8... >>> >>> There is still a question of whether named beans support needs to do >>> the javax.enterprise.inject.spi.InjectionTarget stuff >>> >>> Christian, I ended up going to "beans" as the package name because this >>> supports non-CDI environments (direct instantiation) too. Not overly a fan >>> of "beans" (overloaded term) but it was a lesser of evils. >>> >>> On Thu, Dec 14, 2017 at 10:57 AM Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> Yoann, does this approach still need to do the injections >>>> (javax.enterprise.inject.spi.InjectionTarget)? >>>> >>>> >>>> On Thu, Dec 14, 2017 at 8:01 AM Yoann Rodiere <yoann(a)hibernate.org&gt; >>>> wrote: >>>> >>>>> Here is how it should work from what I understand (adapted from an >>>>> implementation in Search, which has slightly different requirements): >>>>> >>>>> static <T> T getBeanInstance(BeanManager beanManager, String >>>>> beanName, Class<T> contract) { >>>>> Set<Bean<?>> beans = beanManager.getBeans(contract, new >>>>> NamedQualifier(beanName)); >>>>> if ( beans.isEmpty() || beans.size() > 1 ) { >>>>> // TODO proper error messages >>>>> throw new IllegalArgumentException( "No matching beans or multiple >>>>> matching beans" ); >>>>> } >>>>> Bean<?> bean = beans.iterator().next(); >>>>> CreationalContext<T> creationalContext = >>>>> beanManager.createCreationalContext( bean ); >>>>> return contract.cast( beanManager.getReference( bean, contract, >>>>> creationalContext ) ); >>>>> } >>>>> >>>>> With NamedQualifier being the implementation I gave before. >>>>> >>>>> Sure, let's talk about it later on HipChat. Especially the caching >>>>> thing, it's really a blocker for Search. >>>>> >>>>> I'll be online to travel in about 3 hours, though. >>>>> >>>>> >>>>> Yoann Rodière >>>>> Hibernate NoORM Team >>>>> yoann(a)hibernate.org >>>>> >>>>> On 14 December 2017 at 14:46, Steve Ebersole <steve(a)hibernate.org&gt; >>>>> wrote: >>>>> >>>>>> I'll be on HipChat later after I get back from taking my son and >>>>>> daughter to school. Maybe it is easier to discuss there. >>>>>> >>>>>> On Thu, Dec 14, 2017 at 7:44 AM Steve Ebersole <steve(a)hibernate.org&gt; >>>>>> wrote: >>>>>> >>>>>>> But your answer above does not answer my question ;) >>>>>>> >>>>>>> I still have no idea how to go from name+Class -> bean. >>>>>>> >>>>>>> >>>>>>> On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere <yoann(a)hibernate.org&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> Yeah, it was 4AM in France when you asked :) I answered later on >>>>>>>> HipChat, the answer is basically the one I gave in my email. >>>>>>>> >>>>>>>> Yoann Rodière >>>>>>>> Hibernate NoORM Team >>>>>>>> yoann(a)hibernate.org >>>>>>>> >>>>>>>> On 14 December 2017 at 14:38, Steve Ebersole <steve(a)hibernate.org&gt; >>>>>>>> wrote: >>>>>>>> >>>>>>>>> WRT to named beans, I asked Guillaume on HipChat what that is >>>>>>>>> supposed to look like. IIRC he mentioned producers in Paris, but I found >>>>>>>>> no straight-forward way to get from name+class to a bean. >>>>>>>>> >>>>>>>>> He may have answered, I just have not been on HipChat yet today... >>>>>>>>> >>>>>>>>> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole < >>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>> >>>>>>>>>> Its easier to cleanup >>>>>>>>>> >>>>>>>>>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole < >>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>>> >>>>>>>>>>> There are a lot of changes to digest here, but if anyone wanted >>>>>>>>>>> to take a look at this so far... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://github.com/hibernate/hibernate-orm/commit/564ec55ca10c0d5d2afd732... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole < >>>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>>>> >>>>>>>>>>>> Actually my fault. Apparently renaming the package was way >>>>>>>>>>>> too aggressive and renamed the artifact >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole < >>>>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Ah, nm. They change the artifact name. Boo! >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole < >>>>>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven >>>>>>>>>>>>>> Central? It was there last week, but is no longer there... >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole < >>>>>>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for the replies. So unless we hear otherwise from >>>>>>>>>>>>>>> anyone else, I will plan on supporting just one DI container. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere < >>>>>>>>>>>>>>> yoann(a)hibernate.org&gt; wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Same here, compositions don't seem to be a reasonable use >>>>>>>>>>>>>>>> case. And even if >>>>>>>>>>>>>>>> users provide a custom bean registry, they could just >>>>>>>>>>>>>>>> implement their >>>>>>>>>>>>>>>> specific behavior for a few specific case, then retrieve >>>>>>>>>>>>>>>> another >>>>>>>>>>>>>>>> implementations on their own and delegate to it however >>>>>>>>>>>>>>>> they want. >>>>>>>>>>>>>>>> Overriding the service initiator looks like a very >>>>>>>>>>>>>>>> reasonable way to do >>>>>>>>>>>>>>>> that. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regarding the package, "org.hibernate.resource.beans" >>>>>>>>>>>>>>>> seems more >>>>>>>>>>>>>>>> appropriate to me, since CDI is not the only >>>>>>>>>>>>>>>> implementation we will get and >>>>>>>>>>>>>>>> we know it. Also, if I wanted to nitpick, injection is not >>>>>>>>>>>>>>>> really something >>>>>>>>>>>>>>>> the bean registry must provide. We could imagine a bean >>>>>>>>>>>>>>>> registry without >>>>>>>>>>>>>>>> any support for injection, after all, just providing >>>>>>>>>>>>>>>> "monolithic beans". It >>>>>>>>>>>>>>>> would still make sense with respect to your >>>>>>>>>>>>>>>> ManagedBeanRegistry API. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yoann Rodière >>>>>>>>>>>>>>>> Hibernate NoORM Team >>>>>>>>>>>>>>>> yoann(a)hibernate.org >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>>>>>>>>>>> christian.beikov(a)gmail.com&gt; >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > I don't think someone is actually going to use more than >>>>>>>>>>>>>>>> a single DI >>>>>>>>>>>>>>>> > framework and even if they do, they will probably bridge >>>>>>>>>>>>>>>> one way or >>>>>>>>>>>>>>>> > another between the DI frameworks to be able to access >>>>>>>>>>>>>>>> beans from one in >>>>>>>>>>>>>>>> > the other. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > So I don't think we should do "compositions" since it's >>>>>>>>>>>>>>>> not a big deal >>>>>>>>>>>>>>>> > to integrate different DIs and is also IMO an edge case. >>>>>>>>>>>>>>>> I'd prefer the >>>>>>>>>>>>>>>> > package name `org.hibernate.resource.di` since CDI seems >>>>>>>>>>>>>>>> to be just one >>>>>>>>>>>>>>>> > of the possible "integrations". >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Mit freundlichen Grüßen, >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>>>>>>> > *Christian Beikov* >>>>>>>>>>>>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>>>>>>>>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and >>>>>>>>>>>>>>>> friends are mainly >>>>>>>>>>>>>>>> > > about back porting the work I did on 6.0 for the >>>>>>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>>>>>> > > abstraction over dependency injection containers. We >>>>>>>>>>>>>>>> will ship support >>>>>>>>>>>>>>>> > for >>>>>>>>>>>>>>>> > > CDI as well as non-managed beans (things we directly >>>>>>>>>>>>>>>> instantiate). Of >>>>>>>>>>>>>>>> > > course we'd ideally make it easy to plug in other DI >>>>>>>>>>>>>>>> containers such as >>>>>>>>>>>>>>>> > > Spring. So I wanted to discuss the configuration of >>>>>>>>>>>>>>>> this support. >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > The first thing to consider is whether we want to >>>>>>>>>>>>>>>> support using multiple >>>>>>>>>>>>>>>> > DI >>>>>>>>>>>>>>>> > > containers simultaneously. E.g. is it conceivable >>>>>>>>>>>>>>>> that an application >>>>>>>>>>>>>>>> > > might want to use both CDI and Spring simultaneously? >>>>>>>>>>>>>>>> I started building >>>>>>>>>>>>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>>>>>>>>>>>> implementation, >>>>>>>>>>>>>>>> > but >>>>>>>>>>>>>>>> > > stepping back I want to gauge whether that is >>>>>>>>>>>>>>>> "reasonable" before >>>>>>>>>>>>>>>> > > continuing down that path >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > Assuming that we do want to support such >>>>>>>>>>>>>>>> "compositions" the next question >>>>>>>>>>>>>>>> > > is how we see this being configured. Clearly any time >>>>>>>>>>>>>>>> a CDI BeanManager >>>>>>>>>>>>>>>> > is >>>>>>>>>>>>>>>> > > present during bootstrap we want to enable CDI >>>>>>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>>>>>> > > support. How would users indicate additional >>>>>>>>>>>>>>>> ManagedBeanRegistry impls >>>>>>>>>>>>>>>> > be >>>>>>>>>>>>>>>> > > added to the CompositeManagedBeanRegistry? I have >>>>>>>>>>>>>>>> opinions about this, >>>>>>>>>>>>>>>> > but >>>>>>>>>>>>>>>> > > I'd like to hear other's thoughts... >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > Note that ManagedBeanRegistry is a service and is >>>>>>>>>>>>>>>> initiated >>>>>>>>>>>>>>>> > > via >>>>>>>>>>>>>>>> org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it >>>>>>>>>>>>>>>> > > would be possible to completely redefine >>>>>>>>>>>>>>>> ManagedBeanRegistry support >>>>>>>>>>>>>>>> > simply >>>>>>>>>>>>>>>> > > by replacing that initiator. >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > A minor point... notice that the package name here is >>>>>>>>>>>>>>>> > > `org.hibernate.resource.cdi`, even though one of the >>>>>>>>>>>>>>>> goals here is to >>>>>>>>>>>>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want >>>>>>>>>>>>>>>> to use a different >>>>>>>>>>>>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>>>>>>>>>>>> > > ``org.hibernate.resource.di`? >>>>>>>>>>>>>>>> ``org.hibernate.resource.injection`? >>>>>>>>>>>>>>>> > > Other suggestions? I'm actually ok with >>>>>>>>>>>>>>>> `org.hibernate.resource.cdi` - >>>>>>>>>>>>>>>> > imo >>>>>>>>>>>>>>>> > > "cdi" conveys the proper intent. But if others feel >>>>>>>>>>>>>>>> strongly it should >>>>>>>>>>>>>>>> > be >>>>>>>>>>>>>>>> > > something else, I am open to hearing what and why. >>>>>>>>>>>>>>>> > > _______________________________________________ >>>>>>>>>>>>>>>> > > hibernate-dev mailing list >>>>>>>>>>>>>>>> > > hibernate-dev(a)lists.jboss.org >>>>>>>>>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>>>>>> > hibernate-dev mailing list >>>>>>>>>>>>>>>> > hibernate-dev(a)lists.jboss.org >>>>>>>>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>>>> >>