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 <yo...@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
> yo...@hibernate.org
>
> On 14 December 2017 at 14:38, Steve Ebersole <st...@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 <st...@hibernate.org>
>> wrote:
>>
>>> Its easier to cleanup
>>>
>>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole <st...@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 <st...@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 <st...@hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> Ah, nm.  They change the artifact name.  Boo!
>>>>>>
>>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole <st...@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 <st...@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 <yo...@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
>>>>>>>>> yo...@hibernate.org
>>>>>>>>>
>>>>>>>>> On 14 December 2017 at 08:01, Christian Beikov <
>>>>>>>>> christian.bei...@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@lists.jboss.org
>>>>>>>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>> >
>>>>>>>>> > _______________________________________________
>>>>>>>>> > hibernate-dev mailing list
>>>>>>>>> > hibernate-dev@lists.jboss.org
>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>> >
>>>>>>>>> _______________________________________________
>>>>>>>>> hibernate-dev mailing list
>>>>>>>>> hibernate-dev@lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>
>>>>>>>>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Reply via email to