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