esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <esjew...@gmail.com>
Subject Re: Metadata handling (was "Release planning")
Date Tue, 27 Jul 2010 13:30:29 GMT
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 <in.imtiaz@gmail.com> 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" <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