[hibernate-dev] ManagedBeanRegistry - dependency injection support

Steve Ebersole steve at hibernate.org
Thu Dec 14 08:46:27 EST 2017


I'll be on HipChat later after I get back from taking my son and daughter
to school.  Maybe it is easier to discuss there.

On Thu, Dec 14, 2017 at 7:44 AM Steve Ebersole <steve at hibernate.org> wrote:

> But your answer above does not answer my question ;)
>
> I still have no idea how to go from name+Class -> bean.
>
>
> On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere <yoann at hibernate.org> wrote:
>
>> Yeah, it was 4AM in France when you asked :) I answered later on HipChat,
>> the answer is basically the one I gave in my email.
>>
>> Yoann Rodière
>> Hibernate NoORM Team
>> yoann at hibernate.org
>>
>> On 14 December 2017 at 14:38, Steve Ebersole <steve at hibernate.org> wrote:
>>
>>> WRT to named beans, I asked Guillaume on HipChat what that is supposed
>>> to look like.  IIRC he mentioned producers in Paris, but I found no
>>> straight-forward way to get from name+class to a bean.
>>>
>>> He may have answered, I just have not been on HipChat yet today...
>>>
>>> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> Its easier to cleanup
>>>>
>>>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>


More information about the hibernate-dev mailing list