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