[hibernate-dev] ManagedBeanRegistry - dependency injection support

[Steve Ebersole]

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 at 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
> yoann at hibernate.org
>
> On 14 December 2017 at 08:01, Christian Beikov <christian.beikov at 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 at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev