-
Notifications
You must be signed in to change notification settings - Fork 63
[generator] Fix loading broken annotation XML #415
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
||
| static XDocument SafeXmlLoad (Stream s, string fileName) | ||
| { | ||
| // We must save to a temporary file because the stream doesn't support seeking and should the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Must we use a temporary file? As opposed to copying into a MemoryStream?
The largest annotations.xml I see within platform-tools_r28.0.1-darwin.zip is 76017 bytes for android/renderscript/annotations.xml, which isn't that large, and the 76KB should be quickly collectable once it's copied into the (much larger!) XDocument.
| { | ||
| // Google ships not well-formed XML files in the platform-tools 28.0.1 package (in the | ||
| // annotations.zip file), so we need to load the files with a forgiving parser in order to fix | ||
| // them up before loading with a validating XML parser. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably mention https://issuetracker.google.com/issues/116182838, either here, in the commit message, or both. (I like "both". :-)
|
Commit message for merging: |
0efa286 to
edae3b6
Compare
| } catch { | ||
| // ignore | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would think using blocks, you could avoid the need for this method entirely. The empty try-catch is the part we shouldn't really need.
Was there some trouble with a Stream getting double-disposed? It might be there is just a place you need to use an overload of leaveOpen: true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The streams in question aren't placed in using blocks because I don't want to nest the blocks too much and the streams may be null. The method provides for cleaner code and the empty catch is to discard any and all errors in a place where we really don't care about any errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how the streams would be null if using was used?
It seems cleaner to me to just do something like:
static XDocument SafeXmlLoad (Stream s, string fileName)
{
// We must save to a temporary stream because the stream doesn't support seeking and should the
// parsing fail we won't be able to go back to its beginnig to reparse it.
using (var ms = new MemoryStream ()) {
s.CopyTo (ms);
ms.Seek (0, SeekOrigin.Begin);
try {
return XDocument.Load (ms);
} catch (XmlException ex) {
Console.Error.WriteLine ($"Warning: failed to load annotation document '{fileName}' directly from the annotations archive. {ex.Message}");
Console.Error.WriteLine ("Attempting to fix up and reload");
}
try {
using (var ns = FixAnnotationXML (ms))
return XDocument.Load (ns);
} catch (Exception ex) {
throw new InvalidOperationException ($"Failed to fix up invalid XML in annotation document '{fileName}'. {ex.Message}", ex);
}
}
}Context: https://issuetracker.google.com/issues/116182838 Google shipped invalid (not well-formed) XML annotation documents in the `platform-tools` 28.0.1 package, with `<` present within element attributes: <item name="android.view.View void addFocusables(java.util.ArrayList<android.view.View>, int) 1"> Note the `java.util.ArrayList<android.view.View>` within the `//item/@name` attribute value, and that the `<` isn't escaped. This invalid XML prevents System.Xml from loading the `annotations.xml` documents, with errors similar to: android/view/annotations.xml failed: '<', hexadecimal value 0x3C, is an invalid attribute character. Line 206, position 71 This commit takes advantage of the forgiving nature of the HtmlAgilityPack HTML parser -- which loads those files fine -- and makes it possible for us to write them back using `XmlWriter` in order to generate a well-formed XML document which we can load into `XDocument`. Slow, but it works...
edae3b6 to
7e1c797
Compare
|
Timed out... |
|
build |
|
Note: on the next Java.Interop bump within xamarin-android we'll need need to update |
Context: https://issuetracker.google.com/issues/116182838
Google shipped invalid (not well-formed) XML annotation documents in
the
platform-tools28.0.1 package, with<present within elementattributes:
Note the
java.util.ArrayList<android.view.View>within the//item/@nameattribute value, and that the<isn't escaped.This invalid XML prevents System.Xml from loading the
annotations.xmldocuments, with errors similar to:This commit takes advantage of the forgiving nature of the
HtmlAgilityPack HTML parser -- which loads those files fine -- and
makes it possible for us to write them back using
XmlWriterinorder to generate a well-formed XML document which we can load into
XDocument.Slow, but it works...