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

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