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

[Scott Marlow]

With this approach, Hibernate Search/OGM/Custom-Integrator will only 
work with Hibernate ORM 4.1.4 or later.  As long as the SPI doesn't get 
broken in Hibernate 5.x/6.x/7.x/8.x, it might continue to work in 
additional future Hibernate versions also (assuming we keep the design 
in place that long).

The other option on the table, is having a very intimate AS7 dependency 
on org.hibernate.service.internal.BootstrapServiceRegistryImpl class. 
If someone changes 
org.hibernate.service.internal.BootstrapServiceRegistryImpl in Hibernate 
5.x, they won't even know that they broke the integration.  Even if they 
don't change the class but do change the package name, that will break 
Hibernate running on AS7 (with Search/OGM/Custom-Integrator).

The other options were described earlier and involve changing Hibernate 
ORM code to internally handle service loading (would also only work with 
Hibernate ORM 4.1.4 or later).  We didn't come up with a way for 
Hibernate ORM to use any of those suggestions, so we are left with the 
above two (unless there is another way).

On 05/23/2012 09: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