The general problem is that the thread context class loader can be too
generic when you have a mesh of class loaders. As is mentioned in latter
replies in this thread, if classes from a given package namespace have
already been loaded via one class loader, generally all subsequent
classes in the same package should be loaded/defined using the same
class loader. Not doing so will lead to security and type consistency
problems.
In the case of the ejb3 entity manager spi, it does make sense that you
would ask it for the correct class loader for byte code manipulation vs
a class loader to query for resources and do annotation searching.
-----Original Message-----
From: Max Andersen
Sent: Tuesday, January 31, 2006 11:53 PM
To: Emmanuel Bernard; Bill Burke
Cc: Hibernate development; Scott M Stark
Subject: Re: [Hibernate] ClassLoader injection
Hi,
to bill, yes I know ctx current thread is the only way, that was my
whole
point (using ctx current thread in
hibernate was actually the first patch i provided to hibernate core ;)
and yes, having a third classloader concept in the spec sounds like a
very
broken thing.
I would love to hear why it is needed.
/max
> The RI team is going to creak, but I'm inclined to remove it as well.
>
> AS for your first remark, what's wrong with doing getResource with the
> regular classloader? I don't get it.
>
>
> Bill Burke wrote:
>> I understand the need for PUInfo.getNewTempClassLoader() as
>> getResource("META-INF/persistence.xml") may/will return multiples.
>> Also, you may want to introspect the class for annotations before you
>> decide what needs to be bytecode massaged.
>>
>> As for getClassLoader()? I'm not sure of the reasoning. I know
Scott
>> has some spec input on this. Maybe we should get it removed?
>>
>> Emmanuel Bernard wrote:
>>> Year I'm aware of that Bill :-)
>>> But in this case, and like Max said, why on earth the
>>> PersistenceUnitInfo has a getClassLoader() method instead of using
the
>>> context CL?
>>>
>>>
>>> Bill Burke wrote:
>>>
>>>>
>>>>
>>>> Max Rydahl Andersen wrote:
>>>>
>>>>> If it is for the spec then I would argue that the spec is very
wrong
>>>>> since it will
>>>>> break all other kind of stuff. Like how will you convince all the
>>>>> external libraries hibernate
>>>>> uses to use your "magic" classloader ? (e.g. log4j, dom4j, cglib,
>>>>> yada, yada)
>>>>>
>>>>
>>>> Thread.getContextCL() is the only way. If a library doesn't use
>>>> Thread.getCCL() then it is a poorly written library. App server
and
>>>> J2EE in general require this because of classloader isolation
(scoped
>>>> ears or wars). If you are within Hibernate code and call
>>>> Class.forName() it will use the classloader that loaded Hibernate
to
>>>> load the class. (read the javadocs) and you could get CCE, CNF
>>>> exceptions. If you already know this, then apologies.
>>>>
>>>> The same issues effect the loading of resources.
>>>>
>>>> Bill
>>>>
>>>>
>>>
>>>
>>
>
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
[EMAIL PROTECTED]
http://hibernate.org
JBoss Inc
[EMAIL PROTECTED]
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
