[bv-dev] [BVAL-286] Class loading service

[Emmanuel Bernard]

On 20 mai 2012, at 03:10, Michael Nascimento wrote:

> On Sat, May 19, 2012 at 10:11 AM, Gunnar Morling
> <gunnar.morling at googlemail.com> wrote:
>>> Funny that you that. We had just had an Hibernate Validator issue not so
>>> long ago where
>>> a modular system expert told us just the opposite. Don't use TCCL first
>>> ;-)
>>> 
>>> I think the bottom line is that there is no standard. Checking TCCL first
>>> and then the
>>> current class loader was a strategy which Hibernate applied for quite some
>>> time.
>>> It proved to be a good approach for quite some time. However, the current
>>> trend seems to be
>>> to make the class loading more configurable and allow to for example pass
>>> a class loader.
> 
> The point is: yes, it is good and might even to be necessary to have a
> configurable classloading strategy. However, using multiple
> classloaders that you guess as part of the boot process is a terrible
> idea (which is the current approach used by Hibernate). TCCL is the de
> facto standard in Java world and if you choose to use something
> different to the way your environment works, then configure it.
> 
> The bad thing about the way Hibernate did it, as far as I see it, is
> that it is not in the standard (JPA) and it won't use TCCL for a few
> things, requiring you to use a implementation-specific API even for a
> standard environment to work.

In Hibernate ORM, the class loaders are used in the following order:

- application classloader (defaults to TCCL if unset)
- hibernate classloader
- environment classloader (default to system classloader if unset)

There was a bug in the implementation that caused the [issue you mentioned][issue] but that's a bug, not a design flaw 
as far as I can see.

[issue]: https://hibernate.onjira.com/browse/HHH-7084