On 20 mai 2012, at 03:10, Michael Nascimento wrote:
On Sat, May 19, 2012 at 10:11 AM, Gunnar Morling
<gunnar.morling(a)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