[jdom-interest] String index out of range in Beta 7

[Jason Hunter]

You can try Crimson.  It's provided in beta7 also.  The README in the
lib directory explains how to set things up.

-jh-

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
> printStackTrace().
> 
> > 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.
> 
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com