Cool, thank you! I'll apply it in 6-8hrs, same as yesterday, unless Vassil or Anne get to it first.
I do plan to update the tests in a separate commit. Cheers! Ethan On Tuesday, July 27, 2010, Imtiaz Ahmed H E <[email protected]> wrote: > I have attached a 'revised' patch > ESME_branches_metadata_Jira242Fix_Final_Maybe_V2.diff. > to Jira-242. > > Ethan, you will have to tell me exactly why you are not able to commit it, if > you are still not able to do so, so that I can fix the svn diff patch on the > 'metadata' directory under 'branches' in the svn read-only repo. So, > incidentally, you will have to apply the above patch on that directory only > if that makes sense or tell me what... > > ALSO, you need to fix the tests if necessary before commit; two of them fail > now: messages tests 'XML & JSON output' (in the metadata branch build). > > Now, > 1. All code that I commented, which I decided to retain as commented code, is > of one-line comments only now. > 2. Removed unused 'entityDecode' method which had been introduced temporarily > as a sanity check on my understanding of the issue. > > Imtiaz > > ----- Original Message ----- From: "Ethan Jewett" <[email protected]> > To: <[email protected]> > Sent: Monday, July 26, 2010 9:55 PM > Subject: Re: Metadata handling (was "Release planning") > > > > 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 > > > > > >
