Hi, On Fri, 2006-03-03 at 11:29 +0100, Mark Wielaard wrote: > I haven't figured out since when this stopped working, but it clearly is > a regression. If you installed the feature with a working version of > classpath (0.20) and then try to use it with a CVS version you will get > messages like: > !ENTRY org.eclipse.update.configurator 2006-03-03 11:19:10.787 > !MESSAGE Unable to parse file > "/tmp/eclipse/plugins/org.eclipse.cdt.core_3.0.2/plugin.xml". > > So I guess it is something going wrong with the parsing of xml files. > But I haven't found the point yet where eclipse does this, or what the > actual error is that occurs. Christian and I debugged this some more and finally found out that the following patch introduced the regression: "SAX micropatch" http://lists.gnu.org/archive/html/classpath-patches/2006-01/msg00277.html The patch seems completely reasonable. If we get any Exception so we fall out of the parse loop then we report a fatal error, cleanup and reset. Seems obvious since we will indeed not be able to continue with regular processing of the file. But we didn't count on Eclipse... Strangely enough the eclipse PluginParser is a DefaultHandler, that doesn't override fatalError(), and if it has enough data it will throw a subclass of SAXException from its own startElement() handler called ParseCompleteException. It tries to catch this exception from SAXParser.parse() and then continue happily. You can find that code at: http://dev.eclipse.org/viewcvs/index.cgi/*checkout*/org.eclipse.update.configurator/src/org/eclipse/update/internal/configurator/PluginParser.java?rev=HEAD&content-type=text/plain But of course since it threw this exception we, imho correctly, generate a SAXParseException and call fatalError() on the handler which will then throw this since the PluginParser didn't override it. I cannot really see a good way to make eclipse happy. It clearly expects that if it throws this SAXException from startElement() that it will get this exception back as if nothing happened. But since it has just destroyed our parser so we should indeed report a SAXParserException to it (through the errorHandler). Does anyone have a clever idea how to solve this? Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://developer.classpath.org/pipermail/classpath/attachments/20060304/b4c89122/attachment.pgp
