OK, thanks. Is there some type of temporary fix we could do? Like encode
the toString() output manually in that method?
- Dan
James M Snell wrote:
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
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
