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