[jdom-interest] SAXBuilder issues - class cast exception
ahothan at cisco.com
Thu Jun 28 10:53:22 PDT 2001
This problem may be related to how AntClassLoader is implemented. If it was
implemented to behave as a normal class loader you would not have this class cast
exception because it would have used the XMLReader class loaded by the JDK class
loader (also called the Primordial Class Loader): when a ("normal") class loader sees
that a class is not loaded locally, it forward the request to the parent class loader
first, then tries to load it from its class path only after the parent class loader
fails to find/load a class of the same name.
I suspect the AntClassLoader behaves differently, it must load the class locally
before forwarding the request to its parent class loader (sometimes it is useful to
do it this way but this is very tricky to debug). Maybe it is a config parameter of
the Ant tool ?
What you could try is to remove xerces.jar from your AntClassLoader class path and
run it from there. That way your AntClassLoader will have no way to load the class
locally (since it is not in its class path) and will be forced to forward the request
to its parent class (and you'll get the XMLReader class loaded by the PCL).
Hope this helps
Krishnan Anantheswaran wrote:
> Thanks for the pointer. The issue seems to be a
> classloader issue. Ant has its own classloader that it
> uses to create dynamic classpaths for different tasks
> etc. However (some of) the xerces.jar classes are
> loaded by the NetBeans IDE before it uses Ant so this
> uses the system classloader.
> What happens at the end of it all is that the
> org.xml.sax.XMLReader class known to the SAXBuilder is
> loaded thru the Ant classloader and the returned
> XMLReader interface has been created by the JDK
> classloader. Therefore, this results in a class cast
> I *still* can't figure out how to work around this
> issue. If somebody knows please let me know.
> Code and output follows.
More information about the jdom-interest