[jdom-interest] String index out of range in Beta 7
jhunter at collab.net
Tue Jul 17 09:08:57 PDT 2001
You can try Crimson. It's provided in beta7 also. The README in the
lib directory explains how to set things up.
Cyrus Kalbrener wrote:
> This is great, except that it doesn't solve the problem: valid XML docs are
> failing to parse. In this particular case, it seems to be that the lack of
> a PUBLIC entry in the DOCTYPE declaration. Sometimes other documents fail
> to parse and altering a single character in the value of any element will
> make it work.
> It's weird, it's unpredictable, and I need to find a fix for it. I have
> tried several versions of the Xerces parser. Is there another parser that
> might yield better results?
> -----Original Message-----
> From: Jason Hunter [mailto:jhunter at collab.net]
> Sent: Monday, July 16, 2001 12:44 PM
> To: Alex Rosen
> Cc: 'Cyrus Kalbrener'; jdom-interest at jdom.org
> Subject: Re: [jdom-interest] String index out of range in Beta 7
> Alex Rosen wrote:
> > That line in Xerces 1.2.0 is just a re-throw of the real underlying
> > exception in a SAXException. Unfortunately our JDOMException doesn't
> > dive more than one level deep when printing out stack traces, so the
> > *real* cause is lost.
> > I'll submit a patch so that JDOMException will also print out the root
> > stack trace for SAXExceptions. Should I check for other common nested
> > exceptions too? The comment in this bug
> > http://developer.java.sun.com/developer/bugParade/bugs/4209652.html
> > mentions:
> > java.sql.SQLException
> > java.lang.reflect.InvocationTargetException
> > java.lang.ExceptionInInitializerError
> > java.rmi.RemoteException
> > javax.naming.NamingException
> > I can check for all of these, but if we still need to maintain JDK 1.1
> > compatibility, I need to figure out if any of these are new for 1.2 and
> > skip them.
> I think the patch is a great idea. All are core JDK 1.1 except
> NamingException which isn't part of the core even in JDK 1.2.
> ServletException is another exception that can have a root cause. It'd
> be good to handle both, but I don't want to require having the servlet
> library in the classpath in order to build or a JNDI library. Would
> reflection solve the problem? If only there was some overlap!
> getCause() // JDK 1.4 standard naming convention
> getRootCause() // ServletException, NamingException
> getNextException() // SQLException
> getTargetException() // InvocationTargetException
> getException() // ExceptionInInitializerError
> public detail // RemoteException
> Perhaps we could use strong typing for those exceptions in the JDK 1.1
> core: SQLE, ITE, EIIE, RE; and we use reflection for the futures: SE,
> NE, future Throwable. Then reflection only has to handle getRootCause()
> and getCause() which are general enough that other application-specific
> classes might use them too.
> It's interesting, btw, that JDOMException is the only exception class
> that prints its nested exceptions by default when you call
> > In the mean time, when you print out the stack trace, you should be able
> > to do this yourself: call JDOMException.getCause(), and if that's a
> > SAXException, call SAXException.getException(), and print out that stack
> > trace. Or, can you try using the latest Xerces? 1.2.0 is pretty old.
> Yes, as a workaround just print the nested-nested exception's trace.
> To control your jdom-interest membership:
More information about the jdom-interest