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