Hi Imtiaz, Thanks for the new patch. Unfortunately it didn't fix the problem. I can't tell from the reject files what the issue was. In any case, I just went ahead and manually merged. I'm running tests right now, and then I'll commit, so it should show up on the metadata branch in a few minutes.
I'll look into fixing up the tests once that's complete. Ethan On Tue, Jul 27, 2010 at 2:19 PM, Imtiaz Ahmed H E <[email protected]> wrote: > Ethan, > > Use this to patch, ESME_branches_metadata_Jira242Fix_Final_Maybe_V3.diff > It's attached to Jira-242 now. Note the **V3** at the end of this > attachment's name. > > It was made after I undid an incorrect update to a new tortoise svn version > and redid the update correctly. Maybe, just maybe, that was the problem with > your failed commit ? > > Imtiaz > > ----- Original Message ----- From: "Ethan Jewett" <[email protected]> > To: <[email protected]> > Sent: Tuesday, July 27, 2010 11:19 AM > Subject: Re: Metadata handling (was "Release planning") > > > 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 >> >> >> >> >> >> > >
