[hibernate-dev] ManagedBeanRegistry - dependency injection support

[Steve Ebersole]

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