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(a)hibernate.org> wrote:
Its easier to cleanup
On Thu, Dec 14, 2017 at 6:52 AM 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/564ec55ca10c0d5d2afd732...
>
>
> 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
>>>>>
>>>>>