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 Mon, 26 Jul 2010 16:25:55 GMT
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