[hibernate-dev] ManagedBeanRegistry - dependency injection support

[Steve Ebersole]

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 <steve at 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 <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
>
>