Community
Participate
Working Groups
3.0 M4 Need to remove the depencies on Xerces from the Workbench.
Assigning to me for now.
Kim, would you be able to do this?
We only used Xerces explicitly in a few places and migrating was trivial, however, there has been changes in regards to what exceptions need handling. Previously, when we needed to serialize XML we created xerces serializers directly. Using JAXP, we have to go through layers of factories and builders which can throw all kinds of configuration exceptions. Where previously we only needed to worry about IOExceptions we now must worry about many more. I can either catch all internal DOM/SAX configuration exceptions and throw an IOException as a signal of failure or I can change the method signatures to reflect the new fault possibilities. I'd rather just catch/rethrow token IOExeptions (with the text of the originating exception) because: a) we don't anything useful with the IOException anyway (most are just silently caught and ignored, or used to launch dialogs with generic messages) and b) it'd require changing API.
Created attachment 6540 [details] Patch for org.eclipse.ui.workbench
Created attachment 6541 [details] Patch for org.eclipse.ui
Created attachment 6542 [details] Patch for org.eclipse.ui.jface
The above patches go with a) above - all internal XML exceptions are wrapped in an IOException (containing the same stacktrace/message as the original). There was one instance where they were wrapped with a runtime exception because the method signature specified no exceptions. This case, however, will be exceedingly rare. It should only happen if you have a bogus 1.4 runtime (that doesnt have any XML parsers/serializers installed).
Doug, can you please review and release Kim's changes?
Kim: I'm having some problems with your patch. I think it is just a case of a extra unintentional change making it into a classpath, but I want to talk to you to make sure. My specific problems are that org.eclipse.ui.workbench has a fairly significantly altered classpath and project file, some of which don't make sense to me. And one of them breaks the build on Linux. Stop by when you have a chance. Thanks.
I have NO idea how those lines got in there. I edit the .classpath/.project/plugin.xml with a text editor to avoid this automatic munging/augmentation. I tried to duplicate this problem using the same technique but it doesn't happen. I'll keep an eye open for it and will attach new patches.
Created attachment 6568 [details] Patch for org.eclipse.ui.workbench (revised)
(By patches I meant patch - the other two patches seem to be fine)
Note that IE has a problem with saving attachments, particularly when they're patches. It often saves two copies of the attachment back-to-back in the same file. Not sure if this is what you saw.
I know that problem, but that wasn't what I saw. I guess we'll never know what really happened.... :(
This was definitly the case of me generating a bogus patch. I suspect I must've done some editing within the PDE supplied plugin.xml editor which then did the equivilent of "Update Classpath" on me. I've found that running that action results in the same questionable .classpath.
I changed two things before committing the fixes. 1.) Removed the catches for errors thrown by JAXP. From Sun's API: "An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch." 2.) Changed the XMLMemento.createWriteRoot to throw an error if a parser configuration problem occurs. I think that at the point it is a programmatic error or a badly broken XML parser, as we're only using the default configuration. It seems unsafe to keep going at that point. Might be wrong on that one. Let me know if I am....
As long as it doesn't change the method signature I don't think it should matter. If we don't have access to a working XML parser in the VM we probably wont reach any of our points of failure anyways... It looks like there is still JAXP errors being caught in XMLMemento.save()...
Thanks. Removed the other error catches.
Can't find any references to Xerces in *.xml, .classpath or .project files in my workspace (outside of the Xerces plug-in itself and PDE). Verified in I200311192030.
