Bug 368714

Comment 1 Thomas Watson 2012-01-17 09:00:01 EST

(In reply to comment #0)
> Build Identifier: 20110916-0149
> 
> Hi,
> 
> it appears to me that
> org.eclipse.core.runtime.internal.adaptor.ContextFinder#getResource() still
> misses the fix from bug bug 127963 which forwards the call to the
> parentContextClassLoader. Same applies for #findResources().
> 
> The problem appeared for me when trying to load a Hibernate configuration
> (located in main application plugin) from the Hibernate plugin in my RCP
> application. Buddy-strategies failed. I guess this is because of the missing
> forward.
> 
> When I replace the current thread's contextClassLoader by the main plugin's
> classloader (while loading the HBM config) then the mappings can be found by
> Hibernate.
> 
> Can someone please check if the super.getResource() call at lines 149/170 shall
> be replaced in #getResource() method?

In #getResource() method line 149 I think the call to super.getResource is correct since the implementation of ClassLoader[super].getResource delegates to the parent class loader.  The fix in bug 127963 was required to avoid calling super.loadClass because that causes the local native cache to be checked for the class object. We don't have to worry about that for resource loads.

In findResources we make a call to super.findResources, but that simply returns an empty enumeration.  findResources is called by ClassLoader[super].getResources after first calling parent.getResources so in both cases the parent class loader should have been called.  I think something else must be going on.  Why would your resources from Hibernate be loaded from the parent class loader of ContextFinder?  The parent class loader of context finder defaults to the application class loader.  This class loader knows nothing about bundle class loaders and will not find any resources from bundles.

Comment 2 Ralph Schuster 2012-01-17 10:02:41 EST

Thanks for the explanation. This was just a guess.

Well, the loading of additional resources is being done by Hibernate internally. I cannot control.

To repeat the test case: I have a hibernate.cfg.xml that references various mapping files with a path relative to classpath entries. All these files are located in plugin A (main application).

Hibernate code itself is in plugin B and will receive the URL / File of the main HBM file. It successfully loads this main HBM file (by URL.getInputStream()) but fails when opening the mapping files. Changing the paths of these mapping definitions did not solve the problem.

My assumption is that the bundle class loader of B would find the resources in plugin A because A registered as buddy with B.

Meanwhile I found out that I can work around this when subclassing the class that initiates the Hibernate loading within plugin A (main app). I then set the Thread's currentContextClassLoader temporarily to the class loader of my new class.

However, this seems awkward to me that the class loader of plugin B cannot resolve the resource request from Hibernate.

Is there a way to receive more trace information from Eclipse class loaders? So this might shed light on the issue.

Comment 3 Eclipse Genie 2019-10-22 19:50:51 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.

Comment 4 Thomas Watson 2019-10-23 08:54:42 EDT

Without a testcase this is difficult to guess what is going on.  Please reopen if this is still an issue and a testcase can be provided to reproduce.