Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of willem.jiang@gmail.com
 designates 209.85.211.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=kTULWH3yo4y73nBHR8LnfUY5/boscYNKeBipAg1JhSH4dx0OnizMnpB/ekAO70KQLN
         sLyW0gDaYCvX9Iwuv/FtXalgnJfeh60rXBvWOW+MoNDjv/IaOAatxOyVG9YmDXw7Z/e2
         iY5cXgURXqKfQactEx9BqXvNUwdzvdt+36Yck=
Message-ID: <4B4753AD.6060101@gmail.com>
Date: Fri, 08 Jan 2010 23:47:57 +0800
From: Willem Jiang <willem.jiang@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: users@camel.apache.org
Subject: Re: JAXB marshaller & control characters
References: <f2ace7ab0912310523x6b88bfcmc36568cb149bf3f3@mail.gmail.com>
	 <f2ace7ab1001011623qf843f8fp27e9576ca2fac1ce@mail.gmail.com>
	 <4B3EC73C.4000604@gmail.com>
 <4B41B4FE.4070705@gmail.com>	 <4B45A002.5030405@gmail.com>
	 <f2ace7ab1001070843v319845gb03236b5a64a18ed@mail.gmail.com>
	 <f2ace7ab1001071824l34a811cex615222e247534d49@mail.gmail.com>
	 <4B46A862.4000104@gmail.com>
	 <f2ace7ab1001080123k6559e2fs7ad5402f275e5bbd@mail.gmail.com>
	 <4B46FF48.6040709@gmail.com>
 <f2ace7ab1001080706k86d604aw26ca8f3c62e027be@mail.gmail.com>
In-Reply-To: <f2ace7ab1001080706k86d604aw26ca8f3c62e027be@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Pavel,

We need to do the change 1, 2 at the same time.
My old patch can't deal with this situation

from("direct:getJAXBElementValue")
                     .unmarshal(new 
JaxbDataFormat("org.apache.camel.foo.bar"))
                         .to("mock:result");

It's very late for my time, I will work on it tomorrow.

Willem

Pavel wrote:
> Me again.
> I'm trying to hook my writer to the right place and I got confused a bit.
> There are several places that do marshalling/unmarshalling.
> 
> 1. JaxbDataFormat - this is what I think normally steps in when route needs
> to marshal/unmarshal something.
> 
> 2. FallbackTypeConverter - if I read camel docs correctly, this is "last
> resort" converter, not for regular use. (BTW those "if"s in convertTo() look
> suspicious)
> 
> 3. JaxbConverter - I'm not sure what it is. This class is not referenced
> anywhere except tests.
> 
> Can you please clarify that? So far I feel like filtering option needs to be
> applied to #1 only.
> 
> Thanks,
> Pavel
> 
> On Fri, Jan 8, 2010 at 11:47 AM, Willem Jiang <willem.jiang@gmail.com>wrote:
> 
>> Hi Pavel,
>>
>> I think it is OK for us use EasyMock 2.5 as it just for testing.
>> Look forward your XmlStream* solution :)
>>
>> Willem
>>
>>
>>
>> Pavel wrote:
>>
>>> Hi,
>>>
>>> I attached test to JIRA. I'll see if I can put together Xml-based
>>> approach;
>>> will write back on that.
>>>
>>> BTW, do you guys have any objections against updating EasyMock dependency
>>> to
>>> 2.5?
>>>
>>> Thanks,
>>> Pavel
>>>
>>> On Fri, Jan 8, 2010 at 5:37 AM, Willem Jiang <willem.jiang@gmail.com>
>>> wrote:
>>>
>>>  Hi Pavel,
>>>> It's good to keep improving this feature by discussing :)
>>>>
>>>> For the marshal part, I'd like to see your solution which use the
>>>> XmlStreamWriter filtering :)
>>>>
>>>> We can add the option in the JAXBDataFormat to turn on or turn off the
>>>> filtering.
>>>>
>>>> I didn't found the patch of test in your last mail.
>>>> Can you submit the patch into the JIRA[1]?
>>>>
>>>>
>>>> [1] https://issues.apache.org/activemq/browse/CAMEL-2330
>>>>
>>>> Willem
>>>>
>>>>
>>>> Pavel wrote:
>>>>
>>>>  Hi again,
>>>>> I did look at the implementation and I have some thoughts and comments.
>>>>>
>>>>> * This addresses how Camel-JAXB reads XML, which is good. But another
>>>>> aspect is how Camel-JAXB produces XML. E.g. in the case I was hitting,
>>>>> camel/jaxb was marshalling "bad" data that could not be unmarshalled on
>>>>> the
>>>>> other end of the wire.
>>>>>  So I think filtering for the marshalled content needs to be here too.
>>>>>
>>>>> * Yet whole filtering thing needs to be optional. E.g. XML1.1 does not
>>>>> have that restriction, so I would do some sort of config-driven on/off
>>>>> switch.
>>>>>  Camel just does not have enough knowledge about intended payload to
>>>>> make
>>>>> the informed decision.
>>>>>
>>>>> * By default this option should be off for backward compatibility.
>>>>> Otherwise there is a chance of unexpected side effects for those who
>>>>> upgrade.
>>>>>
>>>>> * Would be nice for camel to log the fact of replacement. Silent body
>>>>> modification may be frustrating to users, and add pain to
>>>>> troubleshooting.
>>>>>  - BTW this is the reason why I would go for
>>>>> XmlStreamReader/XmlStreamWriter filtering. It would give mostly the same
>>>>> effect, but in contrast to plain Reader, Xml* classes do know some
>>>>> context.
>>>>> And thus may log meaningful [somewhat] messages.
>>>>>
>>>>>
>>>>>
>>>>> Down to code level, I'm attaching patch with a test for
>>>>> JaxbFilterReader.
>>>>>
>>>>>
>>>>> * I'm not sure the filtering goes exactly per spec referred (
>>>>> http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char).
>>>>> E.g. CR/LF/Tab are filtered out, although these should not be.
>>>>>
>>>>> Also, the spec  mentions 2 slightly different things.
>>>>>
>>>>> 1. Character range. Chars not in that range are not valid for XML 1.0.
>>>>> 2. Discouraged characters (see the "Note:" section). Additional
>>>>> restrictions on top of #1.
>>>>>
>>>>> The test assumes #1. (and I'm having hard times to interpret
>>>>> implications
>>>>> of "discouraged").
>>>>>
>>>>> * Test indicates end-of-stream problem with no-args read(). And I
>>>>> believe
>>>>> there is no need to override no-args read() at all, as it delegates to
>>>>> read(char[], int, int).
>>>>>
>>>>> * I believe there is also an problem in 3-args read(), "len - off" part.
>>>>> I
>>>>> would expect "len" here. Test indicates that issue - unless I missed
>>>>> something and set incorrect expectations.
>>>>>
>>>>>
>>>>> Hope this makes sense.
>>>>>
>>>>> Pavel
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jan 7, 2010 at 6:43 PM, Pavel <pagrus@gmail.com <mailto:
>>>>> pagrus@gmail.com>> wrote:
>>>>>
>>>>>   Hi Willem,
>>>>>
>>>>>   I'm looking into it. It could take some time due to holidays I have,
>>>>>   but I'll come back with feedback as soon as I have it.
>>>>>
>>>>>   Pavel
>>>>>
>>>>>
>>>>>   On Thu, Jan 7, 2010 at 10:49 AM, Willem Jiang
>>>>>   <willem.jiang@gmail.com <mailto:willem.jiang@gmail.com>> wrote:
>>>>>
>>>>>       Hi Pavel,
>>>>>
>>>>>       I committed the patch for CAMEL-2330, You can find the
>>>>>       JaxbFilterReader code here[1].
>>>>>       Please check out last Apache Camel 2.2-SNAPSHOT to verify it.
>>>>>
>>>>>       [1]
>>>>>
>>>>>
>>>>> https://svn.apache.org/repos/asf/camel/trunk/components/camel-jaxb/src/main/java/org/apache/camel/converter/jaxb/JaxbFilterReader.java
>>>>>
>>>>>       Willem
>>>>>
>>>>>
>>>>>       Willem Jiang wrote:
>>>>>
>>>>>           I just filled a JIRA[1] for adding an out of box support in
>>>>>           camel-jaxb.
>>>>>           So you don't need to use covertTo() DSL any more.
>>>>>
>>>>>           [1] https://issues.apache.org/activemq/browse/CAMEL-2330
>>>>>
>>>>>           Willem
>>>>>
>>>>>
>>>>> ...
>>>>>
>>>>>
>>>
>