Hey Imtiaz, The patch looks good from a functionality standpoint. Thanks!
I have one issue and a couple of requests: The issue is that unfortunately the patch isn't applying on my system, even though the last one you submitted worked fine. Error log is below - I'm wondering if you're not working from a completely up to date version of the metadata branch? Can you also make a couple of changes if/when you submit another diff: 1. Can you change the code you need to change by replacing code rather than commenting it out? This should make the diffs a lot cleaner and make it easier to follow changes in SVN. Not a big deal, but I think it makes life a bit easier. 2. It looks to me like the XmlHelper.entityDecode method is not used. I assume it was there because you were using it to try to address my unreasonable decoding demands at some point but are no longer using it :-) Can it be removed? Thanks! Ethan Error log (issues with the API2.scala and XMLHelper.scala files): ethan-jewetts-macbook-pro:metadata esjewett$ patch -p0 -i ~/Desktop/ESME_branches_metadata_final.diff (Stripping trailing CRs from patch.) patching file src/main/scala/org/apache/esme/model/Message.scala (Stripping trailing CRs from patch.) patching file src/main/scala/org/apache/esme/actor/UserActor.scala (Stripping trailing CRs from patch.) patching file src/main/scala/org/apache/esme/actor/Distributor.scala (Stripping trailing CRs from patch.) patching file src/main/scala/org/apache/esme/api/XMLHelper.scala Hunk #1 FAILED at 26. Hunk #2 FAILED at 58. Hunk #3 FAILED at 72. 3 out of 3 hunks FAILED -- saving rejects to file src/main/scala/org/apache/esme/api/XMLHelper.scala.rej (Stripping trailing CRs from patch.) patching file src/main/scala/org/apache/esme/api/API2.scala Hunk #1 FAILED at 56. Hunk #2 FAILED at 65. Hunk #3 FAILED at 333. 3 out of 3 hunks FAILED -- saving rejects to file src/main/scala/org/apache/esme/api/API2.scala.rej On Mon, Jul 26, 2010 at 1:30 AM, Imtiaz Ahmed H E <[email protected]> wrote: > That was my understanding all along ! > > I have submitted a final(?) patch and sample results to Jira-242. Can you > fix the tests, two of them fail, commit and merge back to the main branch. > > Imtiaz > > ----- Original Message ----- From: "Ethan Jewett" <[email protected]> > To: <[email protected]> > Sent: Monday, July 26, 2010 12:00 AM > Subject: Re: Metadata handling (was "Release planning") > > >> Responding to myself because there was indeed something I was >> "fundamentally misunderstanding": >> >> On Sun, Jul 25, 2010 at 8:09 PM, Ethan Jewett <[email protected]> wrote: >>> >>> I think if the user sends non-entity-encoded strings to the API for >>> the metadata, then we need to return the same string. We're returning >>> UTF-8 XML here, not HTML, so my thought was that no one would be >>> expected entity-encoded output. If we return JSON or other formats in >>> the future (and I do plan to do that), then we'll have to encode >>> however necessary for that format. >>> >>> Maybe I'm fundamentally misunderstanding how this output is supposed >>> to be encoded. Encoding is definitely not my area of expertise. >>> >>> If I'm not misunderstanding, then yes, I think we need to decode the >>> entity-encoding so that we see " < and > in the output. I'm not sure >>> if it is currently getting encoded because of something we do or >>> because of Scala's XML handling. >> >> My fundamental misunderstanding was around how you deal with the >> characters <, >, ", ', and & in XML: >> >> http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references#Predefined_entities_in_XML >> >> They indeed must be encoded (though they are a much smaller subset of >> entities that must be encoded than in HTML), so I suppose that we >> should return them in encoded form. Do you agree? >> >> Ethan > >
