|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Jochen Theodorou - 18/Sep/07 08:09 PM
could you please try to remove the xerxes and xalan jars from the lib directory of groovy and then run it again? I think that will solve your problem
Thanks for the guidance on this, for others that might read this, here is what eventually solved the issue:
As per Jochen's suggestion, I removed xerces, though there was no obvious xalan jar in the groovy/lib directory I had, but I also had a file called 'groovysoap-all-1.0-0.3-snapshot_jdk1.5.0.jar' that doesn't seem to be in the current groovy-1.0 distribution so it must have been something I added. At any rate, it has xalan in it, so removing it solved the problem. I'm reopening this issue in hopes of finding a workaround that will let me continue using Groovy 1.0. Below is a quick addition to the script I posted originally that seems to show that the workaround provided (removing xerces and xalan) will allow java.util.Preferences objects to work with XML, but seems to break other xml functionality.
#prefsTest.groovy def prefs = Preferences.userNodeForPackage(this.getClass()); $groovy prefsTest.groovy Is there a way to set a Provider for the DocumentBuilderFactory that won't cause the original ClassCastException when using the xml methods in a prefs object? sorry, I have a small problem in understanding... you did not remove the jars and want to get it working somehow? The flaw is, that java system itself has a parser and does normally load it from there, groovy comes with a parser and prefers that one over the parser from java system. But since loading the parser will use a class from the java system part and a class from the jars of groovy, that duplicates this class. The result is the ClassCastException. That's why suggested removing the jar, because there is no conflict then. removing the jar from RootLoader would work too, but I think there is no method to do something like that.... and in the end it would be the same. The cause for the duplication is the way RootLoader works... it is fine for all things but the xml parser. I am not sure about that, but I guess there is no usable way.
I'm sorry, I should have been more clear, I did remove the jars as suggested, which fixes the call to prefs.exportSubtree(System.out) - but if I then try to call DocumentBuilderFactory.newInstance(), it will fail with the following exception:
Caught: javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.DocumentBuilderFactory cannot be found ...which happens because the jars have been removed. Setting the system property for javax.xml.parsers.DocumentBuilderFactory to anything other than the included xerces parser seems to cause a ClassCastException. I did manage to find a workaround though that allows me to continue working with Groovy 1.0 that only requires a small code workaround, which is as follows: 1. Do not remove any of the files from the groovy-1.0/lib directory. ...to bypass the xml parser included in Groovy. Once finished with the offending calls, use: ...to reset the parser factory back to its original setting. This workaround allows me to continue to use Groovy 1.0 (and hence the eclipse plugin) so as far as I'm concerned the issue is closed, but I will leave it open in the issue tracker in case you have further comments on it. Feel free to close it if you don't. I did notice that Guillaume Laforge changed the fixed version from 1.1-beta2 to rc1, I just thought I should mention that I have tested it under beta 2 and my code did work, but I haven't tested it under rc1 at all. Thank you for your input in helping me solve this problem. Here is the original test case script with the fix implemented:
import java.util.prefs.*; System.setProperty('javax.xml.parsers.DocumentBuilderFactory','com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl'); def prefs = Preferences.userNodeForPackage(this.getClass()); |
|||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
ClassCastException when using java.util.prefs package