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:
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(a)hibernate.org
On 14 December 2017 at 13:52, Steve Ebersole <steve(a)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(a)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(a)hibernate.org>
> wrote:
>
>> Ah, nm. They change the artifact name. Boo!
>>
>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole <steve(a)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(a)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(a)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(a)hibernate.org
>>>>>
>>>>> On 14 December 2017 at 08:01, Christian Beikov <
>>>>> christian.beikov(a)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(a)lists.jboss.org
>>>>> > >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>> >
>>>>> > _______________________________________________
>>>>> > hibernate-dev mailing list
>>>>> > hibernate-dev(a)lists.jboss.org
>>>>> >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>> >
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>>