incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Imtiaz Ahmed H E" <in.imt...@gmail.com>
Subject Re: Metadata handling (was "Release planning")
Date Tue, 27 Jul 2010 12:19:31 GMT
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" <esjewett@gmail.com>
To: <esme-dev@incubator.apache.org>
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 <in.imtiaz@gmail.com> 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" <esjewett@gmail.com>
> To: <esme-dev@incubator.apache.org>
> 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 <in.imtiaz@gmail.com> 
> 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" <esjewett@gmail.com>
> To: <esme-dev@incubator.apache.org>
> 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 <esjewett@gmail.com> 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
>
>
>
>
>
> 


Mime
View raw message