[hibernate-dev] ManagedBeanRegistry - dependency injection support

[Steve Ebersole]

Ah, nm.  They change the artifact name.  Boo!

On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole <steve at 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 <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
>>
>>