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 <yo...@hibernate.org> 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 > yo...@hibernate.org > > On 14 December 2017 at 14:38, Steve Ebersole <st...@hibernate.org> 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 <st...@hibernate.org> >> wrote: >> >>> Its easier to cleanup >>> >>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole <st...@hibernate.org> >>> 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 <st...@hibernate.org> >>>> 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 <st...@hibernate.org> >>>>> wrote: >>>>> >>>>>> Ah, nm. They change the artifact name. Boo! >>>>>> >>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole <st...@hibernate.org> >>>>>> 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 <st...@hibernate.org> >>>>>>> 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 <yo...@hibernate.org> >>>>>>>> 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 >>>>>>>>> yo...@hibernate.org >>>>>>>>> >>>>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>>>> christian.bei...@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@lists.jboss.org >>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>> > >>>>>>>>> > _______________________________________________ >>>>>>>>> > hibernate-dev mailing list >>>>>>>>> > hibernate-dev@lists.jboss.org >>>>>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>> > >>>>>>>>> _______________________________________________ >>>>>>>>> hibernate-dev mailing list >>>>>>>>> hibernate-dev@lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>> >>>>>>>> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
