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 04:37:41 GMT
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