On 05/22/2012 04:58 PM, Steve Ebersole wrote:
On Tue 22 May 2012 03:50:31 PM CDT, Scott Marlow wrote:
> For EE JPA deployments, we can also inject the Hibernate
> OGM/Search/Other Integrator classloader set into
> org.hibernate.cfg.AvailableSettings#INTEGRATOR_CLASSLOADER (as a set).
>
> For nonEE-JPA/Hibernate applications to use Hibernate Search/OGM/Other
> Integrator implementations on AS7, introducing an AS7 deployment API
> that native applications could call to get the jboss-hibernate.xml
> specified dependencies (classloader set) sounds ugly but would be one
> implementation. A cleaner way would be to have some type of Hibernate
> deployer that could deploy/start Native Hibernate applications (instead
> of application code handling that).
Just to be clear, this AvailableSettings#INTEGRATOR_CLASSLOADER
capability does not exist today. And adding it adds a new complexity of
having to ascertain the Hibernate version being used in order to know
whether that capability exists.
There were a couple of solutions discussed with David on IRC. All have
ugliness associated. The one I personally hated the least was to use
bytecode enhancement on Hibernate's
org.hibernate.service.internal.BootstrapServiceRegistryImpl class to
inject in the Integrators whenever that class gets instantiated (the
difficulty that requires bytecode manip here is that the app itself is
actually the one instantiating this class). I think thats the most
consistent solution across all of the deployment scenarios and it
isolates the funkiness to the JBoss/Hibernate integration.
I like the idea, not sure how we want to implement yet. Are there any
other ways that we might hook into
org.hibernate.service.internal.BootstrapServiceRegistryImpl? I think
that a static SPI class method that allows me to register a callback
that BootstrapServiceRegistryImpl would invoke, might introduce a
stronger contract that isn't forgotten about as easily in future
Hibernate releases.
What do you think?
--
steve(a)hibernate.org
http://hibernate.org