[jboss-as7-dev] Modularity is the spawn of Lucifer and a stinking donkey

[David M. Lloyd]

We don't ship them.  Only our provided Hibernate(s) would need such a 
hook.  If the customer bundles it in their deployment, we don't need to 
do anything like this anyway.

On 05/23/2012 08:18 AM, Steve Ebersole wrote:
> My concern with the SPI contract approach is that it requires code
> change on the Hibernate side to actually be available. So what do we do
> with versions of Hibernate that dont have that SPI contract?
>
> On Tue 22 May 2012 06:53:23 PM CDT, Scott Marlow wrote:
>> 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 at hibernate.org
>>> http://hibernate.org
>>
>
> --
> steve at hibernate.org
> http://hibernate.org


-- 
- DML