Solfire
asked on
Wierd EmptyStackException from SAX
Hello,
I have written a class which utilizes the SAX api in JDK 1.4 in order to parse XML files. When running a small TesterUtility which I wrote to test it through the IDE everything works fine, however when running from the command line I kept on getting a java.util.EmptyStackExcept
Since generally such problems come from a bad classpath, I added:
System.out.println(System.
in the begginning of the tester, and then began checking dir by dir which one was lacking.
After a while I found the when placing one of Fortes modules ('wasp-advanced.jar') in the classpath solved the problem and allowed the program to run from the command line as well. Now this is odd for two reasons:
a) I have absolutley no dependencies on wasp-advanced.jar, as does the SAX api. I have verified this by running a verbose output
b) The exception thrown was a java.util.EmptyStackExcept
Unfortunatley the problem was not solved by simply adding the module into the classpath. I also need this to run under Tomcat, and placing the aforementioned module into Tomcats 'lib' directory does not help, and I still receive the same error.
So just to sum it all up:
a) The program worked fine under the IDE
b) Did not work under console until a single jar, wasp-advanced.jar, one of Forte's modules, was placed into the classpath. There are no dependencies on the jar file *verified* by running verbose output.
c) Adding this module into tomcat lib directory does not help, and the same EmptyStackException is still thrown, as if running from command prompt without correct classpath.
If anybody has any insight as to the origin of this error and/or suggestions for a solution they would be very much appreciated.
I have written a class which utilizes the SAX api in JDK 1.4 in order to parse XML files. When running a small TesterUtility which I wrote to test it through the IDE everything works fine, however when running from the command line I kept on getting a java.util.EmptyStackExcept
Since generally such problems come from a bad classpath, I added:
System.out.println(System.
in the begginning of the tester, and then began checking dir by dir which one was lacking.
After a while I found the when placing one of Fortes modules ('wasp-advanced.jar') in the classpath solved the problem and allowed the program to run from the command line as well. Now this is odd for two reasons:
a) I have absolutley no dependencies on wasp-advanced.jar, as does the SAX api. I have verified this by running a verbose output
b) The exception thrown was a java.util.EmptyStackExcept
Unfortunatley the problem was not solved by simply adding the module into the classpath. I also need this to run under Tomcat, and placing the aforementioned module into Tomcats 'lib' directory does not help, and I still receive the same error.
So just to sum it all up:
a) The program worked fine under the IDE
b) Did not work under console until a single jar, wasp-advanced.jar, one of Forte's modules, was placed into the classpath. There are no dependencies on the jar file *verified* by running verbose output.
c) Adding this module into tomcat lib directory does not help, and the same EmptyStackException is still thrown, as if running from command prompt without correct classpath.
If anybody has any insight as to the origin of this error and/or suggestions for a solution they would be very much appreciated.
another option - try recompiling your project with command line javac.
ASKER
voren:
Well, I have already verified by using verbose output that nothing is being loaded from wasp-advanced.jar (everything comes from rt.jar, as is expected). The check you suggested returns the same result. Also, wouldn't the interpreter report any ambigous classes in it's classpath? i.e. when attempting to load classes with same name?
heyhey:
Unfortunatley by the time I read your message I had already rewritten the class to use a different XML package (namely EXML, www.themindelectric.com) which works fine. When I get home and a backup copy is available I will try a command line compile.
Well, I have already verified by using verbose output that nothing is being loaded from wasp-advanced.jar (everything comes from rt.jar, as is expected). The check you suggested returns the same result. Also, wouldn't the interpreter report any ambigous classes in it's classpath? i.e. when attempting to load classes with same name?
heyhey:
Unfortunatley by the time I read your message I had already rewritten the class to use a different XML package (namely EXML, www.themindelectric.com) which works fine. When I get home and a backup copy is available I will try a command line compile.
ASKER
voren:
Well, I have already verified by using verbose output that nothing is being loaded from wasp-advanced.jar (everything comes from rt.jar, as is expected). The check you suggested returns the same result. Also, wouldn't the interpreter report any ambigous classes in it's classpath? i.e. when attempting to load classes with same name?
heyhey:
Unfortunatley by the time I read your message I had already rewritten the class to use a different XML package (namely EXML, www.themindelectric.com) which works fine. When I get home and a backup copy is available I will try a command line compile.
Well, I have already verified by using verbose output that nothing is being loaded from wasp-advanced.jar (everything comes from rt.jar, as is expected). The check you suggested returns the same result. Also, wouldn't the interpreter report any ambigous classes in it's classpath? i.e. when attempting to load classes with same name?
heyhey:
Unfortunatley by the time I read your message I had already rewritten the class to use a different XML package (namely EXML, www.themindelectric.com) which works fine. When I get home and a backup copy is available I will try a command line compile.
Solfire,
I have worked quite a bit with Crimson and have never encountered an XML file that gives an EmptyStackException. Can you post or email (yuval@bluecast.com) the file?
Regarding the ambiguous class question, the class names for the parsers are not the same. If you're using XMLReaderFactory or JAXP to instantiate the parser, it uses a system property (org.xml.sax.driver) or service identitifer (META-INF/services/javax.x
I have worked quite a bit with Crimson and have never encountered an XML file that gives an EmptyStackException. Can you post or email (yuval@bluecast.com) the file?
Regarding the ambiguous class question, the class names for the parsers are not the same. If you're using XMLReaderFactory or JAXP to instantiate the parser, it uses a system property (org.xml.sax.driver) or service identitifer (META-INF/services/javax.x
Ignore that last comment. You specifically said the class name was Crimson. In this case, you've got one of the following:
- corrupt bytecode (fixed as heyhey said)
- a corrupt JDK (would need to reinstall)
- an actual bug in Crimson
- corrupt bytecode (fixed as heyhey said)
- a corrupt JDK (would need to reinstall)
- an actual bug in Crimson
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:
- To be PAQ'ed and points NOT refunded
Please leave any comments here within the
next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER !
girionis
Cleanup Volunteer
I will leave a recommendation in the Cleanup topic area that this question is:
- To be PAQ'ed and points NOT refunded
Please leave any comments here within the
next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER !
girionis
Cleanup Volunteer
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
How are you instantiating the parser? Try adding a line to see what parser you're using. Assuming you have a line like:
[XMLReader reader = ....]
Add:
System.out.println("Parser
+ reader.getClass().getName(
As far as the EmptyStackException, that's not a classpath issue but rather an error parsing your document. It might be a bug in Crimson, and adding wasp-advanced.jar might be fixing it by using a different parser altogether.