[hibernate-dev] ManagedBeanRegistry - dependency injection support
Steve Ebersole
steve at hibernate.org
Thu Dec 14 08:38:43 EST 2017
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