5:54 a.m.
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