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(a)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(a)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(a)hibernate.org
>
> On 14 December 2017 at 14:38, Steve Ebersole <steve(a)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(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
>>>>>>>>
>>>>>>>>
>