[hibernate-dev] ManagedBeanRegistry - dependency injection support

[Steve Ebersole]

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 <steve at 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 <steve at hibernate.org>
> wrote:
>
>> 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
>>>>
>>>>