Re: [hibernate-dev] ManagedBeanRegistry - dependency injection support

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