Dan, after reviewing this further, I do not think this patch is a good idea. Atom explicitly allows documents to contain IRI's, which means applications using Abdera should not have to be forced to use the converted URI form in the @src attribute. The correct fix would be to make sure that the toString() method returns the appropriate results instead of forcing the results to the ASCII URI form.
- James Dan Diephouse wrote: > [EMAIL PROTECTED] wrote: >> Author: jmsnell >> Date: Fri Oct 12 16:21:49 2007 >> New Revision: 584318 >> >> URL: http://svn.apache.org/viewvc?rev=584318&view=rev >> Log: >> Commit https://issues.apache.org/jira/browse/ABDERA-73. There was one >> change to FOMEntry included in the patch that I omitted from this as >> it did not appear to be directly relevant. >> >> > Hi James, thanks for applying my patch! > > Was there anything wrong with this change: > > Index: parser/src/main/java/org/apache/abdera/parser/stax/FOMEntry.java > =================================================================== > --- parser/src/main/java/org/apache/abdera/parser/stax/FOMEntry.java > (revision 584433) > +++ parser/src/main/java/org/apache/abdera/parser/stax/FOMEntry.java > (working copy) > @@ -313,7 +313,7 @@ > try { > FOMFactory factory = (FOMFactory) this.factory; > Content content = factory.newContent(new MimeType(mediatype)); > - content.setSrc(uri.toString()); > + content.setSrc(uri.toASCIIString()); > setContentElement(content); > return content; > } catch (javax.activation.MimeTypeParseException e) { > > My application doesn't work correctly without it because my IRI has > spaces in it sometimes. Since we're converting it to a String for the > <content> element we need to encode these characters. > > - Dan >
