[hibernate-dev] ManagedBeanRegistry - dependency injection support
Yoann Rodiere
yoann at hibernate.org
Thu Dec 14 08:24:06 EST 2017
Thanks. As mentioned on the commit, I'm wondering if it's such a good idea
to cache the beans... Like you seem to do here:
https://github.com/hibernate/hibernate-orm/commit/564ec55ca10c0d5d2afd73243dc0aa31759e8f5b#diff-8daedd2dae71b88377be643ed78b5c5dR33
CDI already has features to make sure that a given bean is a singleton, and
sometimes (in Search in particular) we absolutely do not want the beans to
be singletons, but rather want to instantiate them multiple times. So... is
it really necessary?
Also the current implementation doesn't seem to support actual named beans,
which would be fetched by calling "beanManager.getBeans(clazz, new
NamedQualifier(name))" where NamedQualifier would be defined as below (not
a joke, it looks like it's actually what we should do).
private static class NamedQualifier extends
javax.enterprise.util.AnnotationLiteral<Named> implements
javax.inject.Named {
private final String name;
public NamedQualifier(String name) {
this.name = name;
}
@Override
public String value() {
return name;
}
}
Yoann Rodière
Hibernate NoORM Team
yoann at hibernate.org
On 14 December 2017 at 13:52, 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