Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 129733

Summary: ClassCastException with crimson & xerces
Product: [Eclipse Project] Equinox Reporter: Eran Bartenstein <eranb>
Component: FrameworkAssignee: equinox.framework-inbox <equinox.framework-inbox>
Status: RESOLVED DUPLICATE QA Contact:
Severity: major    
Priority: P3 CC: Darin_Swanson
Version: 3.1.1   
Target Milestone: ---   
Hardware: PC   
OS: Windows 2000   
Whiteboard:

Description Eran Bartenstein CLA 2006-02-28 04:19:21 EST
When trying to use a firstDoc.importNode(secondDocNode) I get a ClassCastException. Both document, firstDoc and the one that secondDocNode belongs to where cerated in the same way: using: DocumentBuilderFactory.newInstance().
The documents ceation were made from 2 calls on the same class under the same thread. 
This happend because the documents created with a different DOM implementation. The implementation uses the generic java interface: DocumentBuilderFactory.newInstance(). 
During my investigation of the problem I have found out the problem occures only when the code, which is run from a plugin of mine, is run on the second time right after opening a build.xml file with the 'ant editor' - chosen from the 'open with' sub menu in the package explorer.

That made me inestigate some more and find out the following:
In the first call to DocumentBuilderFactory.newInstance(), which created firstDoc, the thread is the same as in the second call, the classloaders of the classes in play are the same.
However, though the thread is the same, its classloader is different between the 2 calls. In the first, the classloader is:
org.eclipse.core.runtime.internal.adaptor.ContextFinder@17d5d2a
, where in the second it is: 
org.eclipse.ant.internal.core.AntClassLoader@1ee4826

It seems that the class loader is replaced by the eclipse under the same thread.
Comment 1 Thomas Watson CLA 2006-02-28 09:40:18 EST
CC'ing Darin from ant support.

Darin, it appears that ant is setting the thread context classloader and never restores it back to the original classloader.  Can you check to see if this is what is happening in the ant support?  Also, does the ant support include a parser implementation?
Comment 2 Darin Swanson CLA 2006-02-28 10:22:05 EST
The Ant bundled with Eclipse does not provide any XML parsing implementation. The user can add XML parsing JARs to the Ant runtime classpath though.

Reviewing the code, we do set the context class loader to the Ant classloader during Ant buildfile parsing but in a finally block we restore the original context classloader.

I will see if I can reproduce the problem.
Comment 3 Darin Swanson CLA 2006-03-28 16:32:05 EST
I believe this is a duplicate of bug 131693 which I am working on a fix.
Comment 4 Pascal Rapicault CLA 2006-04-05 11:51:54 EDT

*** This bug has been marked as a duplicate of 131693 ***