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
