You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Pavel <pa...@gmail.com> on 2009/12/31 14:23:33 UTC
JAXB marshaller & control characters
Hi,
I'm looking for the way to filter out control characters prohibited by XML
spec at/after marshalling. Otherwise consumers are unable to unmarshal the
content.
Is there an out of the box means for doing that? If not, can you recommend
the right way for doing that?
I just did similar exercise with CXF, there it was took creating custom
XMLStreamWriter and using outbound interceptor to replace original writer
with custom one.
Thanks,
Pavel
Re: JAXB marshaller & control characters
Posted by Pavel <pa...@gmail.com>.
Ha, I thought EasyMock was alreay a framework of choice. As that's not the
case, I'm going to give Mockito a try and convert camel-jaxb tests. If all
goes well I'll get back with a patch after the weekend.
Thanks,
Pavel
On Sat, Jan 9, 2010 at 7:48 AM, Claus Ibsen <cl...@gmail.com> wrote:
> On Fri, Jan 8, 2010 at 7:38 PM, Stephen Gargan <st...@gmail.com>
> wrote:
> > Pavel,
> >
> > Mock Frameworks are a subjective kind of thing, but I've had a lot of
> > luck with Mockito. It's DSL (And we're fans of good DSLs round here ;)
> > ) is really clean and succinct and the Argument Capture I've found
> > indispensible.
> >
> > http://www.mockito.org/
> >
>
> I have heard good things about Mockito too as well.
> However we do not use EasyMock that much in testing Camel. So its not
> a big deal to upgrade to include both of them.
> And maybe migrate to Mockito and start using it more :)
>
>
>
> > And I've also found Mycila very useful for injecting mocks into spring
> > contexts, it will work with easymock too if you prefer
> >
> > http://code.google.com/p/mycila/wiki/MycilaTesting
> >
> > checkit.
> >
> > ste
> >
> >
> >
> > On Fri, Jan 8, 2010 at 7:47 AM, Willem Jiang <wi...@gmail.com>
> wrote:
> >> 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
>
...
Re: JAXB marshaller & control characters
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Jan 8, 2010 at 7:38 PM, Stephen Gargan <st...@gmail.com> wrote:
> Pavel,
>
> Mock Frameworks are a subjective kind of thing, but I've had a lot of
> luck with Mockito. It's DSL (And we're fans of good DSLs round here ;)
> ) is really clean and succinct and the Argument Capture I've found
> indispensible.
>
> http://www.mockito.org/
>
I have heard good things about Mockito too as well.
However we do not use EasyMock that much in testing Camel. So its not
a big deal to upgrade to include both of them.
And maybe migrate to Mockito and start using it more :)
> And I've also found Mycila very useful for injecting mocks into spring
> contexts, it will work with easymock too if you prefer
>
> http://code.google.com/p/mycila/wiki/MycilaTesting
>
> checkit.
>
> ste
>
>
>
> On Fri, Jan 8, 2010 at 7:47 AM, Willem Jiang <wi...@gmail.com> wrote:
>> 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
>>> <wi...@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 <wi...@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 <ma...@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
>>>>>>>
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: JAXB marshaller & control characters
Posted by Stephen Gargan <st...@gmail.com>.
Pavel,
Mock Frameworks are a subjective kind of thing, but I've had a lot of
luck with Mockito. It's DSL (And we're fans of good DSLs round here ;)
) is really clean and succinct and the Argument Capture I've found
indispensible.
http://www.mockito.org/
And I've also found Mycila very useful for injecting mocks into spring
contexts, it will work with easymock too if you prefer
http://code.google.com/p/mycila/wiki/MycilaTesting
checkit.
ste
On Fri, Jan 8, 2010 at 7:47 AM, Willem Jiang <wi...@gmail.com> wrote:
> 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
>> <wi...@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 <wi...@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 <ma...@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
>>>>>>
>>>>>>
>>>>>> ...
>>>>>>
>>>>>>
>>>>
>>
>
>
Re: JAXB marshaller & control characters
Posted by Willem Jiang <wi...@gmail.com>.
Hi Pavel,
I just committed your patch with some of my change.
I added a comment in the JIRA[1], please check it out.
Now we need update the wiki page and finish the FallbackTypeConverter
marshal part.
I will keep on working them tomorrow.
[1] https://issues.apache.org/activemq/browse/CAMEL-2330
Willem
Willem Jiang wrote:
> Hi Pavel,
>
> I have a quick look at the patch, you did a good test on your code.
> Just some minor issues,
> 1. You just check the Exchange property in JaxbDataFormat marshal(), and
> check the filterNonXmlChars in JaxbDataFormat unmarshal method.
> My suggestion is let the exchange property override the configure of
> JaxbDataFormat that is same with other Camel components do.
>
> 2. When unmarshaling the InputStream, you need to get the
> CharsetEncoding from Exchange like this
>
> answer = unmarshaller.unmarshal(new NonXmlFilterReader(new
> InputStreamReader(stream, IOConvertor(getCharsetName(exchange))));
>
> I will apply the patch later today after I finish the parts which you
> don't start.
>
> Have a nice weekend :)
>
> Willem
>
>
> Pavel wrote:
>> Hi - Just in case I'm attaching patch of what I have so far. Not
>> uploading to JIRA, as patch is incomplete, yet it may correlate with
>> what you want to do. Here are the highlights:
>>
>> * Marshalling uses custom XmlStreamWriter, while unmarshalling relies
>> on the same, non-xml reader. I realized that wrapping XmlStreamReader
>> does not solve the problem, as wrapper has no power to prevent
>> underlying reader from reading bad chars and failing therefore.
>>
>> * Filtering has changed slightly - it replaces bad chars with space
>> chars. This a) allows to get rid of intemediate buffer and simplify
>> the code and b) is consistent with the way e.g. Woodstox performs
>> similar filtering.
>>
>> * It is exchange property or data format property that turns filtering
>> on/off.
>>
>> * NonXmlCharFilterer performs logging of the replacement fact in case
>> of char[]; and more readable message in case of String.
>>
>> What's not done:
>> * I did hook filtering to data format, but did not change converter yet.
>> * Filtering option for JAXB data format is not exposed via spring DSL
>> yet.
>>
>> LMK if you have a feedback.
>>
>> Thanks,
>> Pavel
>>
Re: JAXB marshaller & control characters
Posted by Willem Jiang <wi...@gmail.com>.
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 <wi...@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 <wi...@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 <ma...@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
>>>>>
>>>>>
>>>>> ...
>>>>>
>>>>>
>>>
>
Re: JAXB marshaller & control characters
Posted by Pavel <pa...@gmail.com>.
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 <wi...@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 <wi...@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 <ma...@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
>>>>
>>>>
>>>> ...
>>>>
>>>>
>>>
>>
>>
>
Re: JAXB marshaller & control characters
Posted by Willem Jiang <wi...@gmail.com>.
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 <wi...@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 <ma...@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
>>>
>>>
>>> ...
>>>
>>
>
>
Re: JAXB marshaller & control characters
Posted by Pavel <pa...@gmail.com>.
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 <wi...@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 <ma...@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
>>
>>
>> ...
>>
>
>
--
Best regards,
Pavel
Re: JAXB marshaller & control characters
Posted by Willem Jiang <wi...@gmail.com>.
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
> <ma...@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 <ma...@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
>
>
> ...
Re: JAXB marshaller & control characters
Posted by Pavel <pa...@gmail.com>.
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 <pa...@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 <wi...@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
>>>
>>>
>>> ...
Re: JAXB marshaller & control characters
Posted by Pavel <pa...@gmail.com>.
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 <wi...@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
>>
>>
>> Willem Jiang wrote:
>>
>>> Hi,
>>>
>>> I think you can write a type converter[1] which can turn the InputStream
>>> to a JAXB safe (which filters the control characters) InputStream.
>>>
>>> Then can define your route like this
>>>
>>> from("direct:start").covertTo(JaxbSafeInputStream.class).unmarshal(new
>>> JaxbDataFormat("org.apache.camel.example")).to("mock:endpoint");
>>>
>>> If so I'd like to integrate it into camel-jaxb :)
>>>
>>> [1] http://camel.apache.org/type-converter.html
>>>
>>> Willem
>>>
>>>
>>> Pavel wrote:
>>>
>>>> I found a few relevant links:
>>>>
>>>> http://old.nabble.com/UTF-8-characters-jaxb-td25531336.html#a25531336
>>>> http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char
>>>>
>>>> Seems like this topic was discussed already, but I'm not if relevant
>>>> replacement mechanism made it into camel.
>>>>
>>>> Pavel
>>>>
>>>> On Thu, Dec 31, 2009 at 3:23 PM, Pavel <pa...@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>>
>>>>> I'm looking for the way to filter out control characters prohibited by
>>>>> XML
>>>>> spec at/after marshalling. Otherwise consumers are unable to unmarshal
>>>>> the
>>>>> content.
>>>>>
>>>>> Is there an out of the box means for doing that? If not, can you
>>>>> recommend
>>>>> the right way for doing that?
>>>>>
>>>>> I just did similar exercise with CXF, there it was took creating custom
>>>>> XMLStreamWriter and using outbound interceptor to replace original
>>>>> writer
>>>>> with custom one.
>>>>>
>>>>> Thanks,
>>>>> Pavel
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
Re: JAXB marshaller & control characters
Posted by Willem Jiang <wi...@gmail.com>.
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
>
>
> Willem Jiang wrote:
>> Hi,
>>
>> I think you can write a type converter[1] which can turn the
>> InputStream to a JAXB safe (which filters the control characters)
>> InputStream.
>>
>> Then can define your route like this
>>
>> from("direct:start").covertTo(JaxbSafeInputStream.class).unmarshal(new
>> JaxbDataFormat("org.apache.camel.example")).to("mock:endpoint");
>>
>> If so I'd like to integrate it into camel-jaxb :)
>>
>> [1] http://camel.apache.org/type-converter.html
>>
>> Willem
>>
>>
>> Pavel wrote:
>>> I found a few relevant links:
>>>
>>> http://old.nabble.com/UTF-8-characters-jaxb-td25531336.html#a25531336
>>> http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char
>>>
>>> Seems like this topic was discussed already, but I'm not if relevant
>>> replacement mechanism made it into camel.
>>>
>>> Pavel
>>>
>>> On Thu, Dec 31, 2009 at 3:23 PM, Pavel <pa...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm looking for the way to filter out control characters prohibited
>>>> by XML
>>>> spec at/after marshalling. Otherwise consumers are unable to
>>>> unmarshal the
>>>> content.
>>>>
>>>> Is there an out of the box means for doing that? If not, can you
>>>> recommend
>>>> the right way for doing that?
>>>>
>>>> I just did similar exercise with CXF, there it was took creating custom
>>>> XMLStreamWriter and using outbound interceptor to replace original
>>>> writer
>>>> with custom one.
>>>>
>>>> Thanks,
>>>> Pavel
>>>>
>>>
>>
>>
>
>
Re: JAXB marshaller & control characters
Posted by Willem Jiang <wi...@gmail.com>.
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
Willem Jiang wrote:
> Hi,
>
> I think you can write a type converter[1] which can turn the InputStream
> to a JAXB safe (which filters the control characters) InputStream.
>
> Then can define your route like this
>
> from("direct:start").covertTo(JaxbSafeInputStream.class).unmarshal(new
> JaxbDataFormat("org.apache.camel.example")).to("mock:endpoint");
>
> If so I'd like to integrate it into camel-jaxb :)
>
> [1] http://camel.apache.org/type-converter.html
>
> Willem
>
>
> Pavel wrote:
>> I found a few relevant links:
>>
>> http://old.nabble.com/UTF-8-characters-jaxb-td25531336.html#a25531336
>> http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char
>>
>> Seems like this topic was discussed already, but I'm not if relevant
>> replacement mechanism made it into camel.
>>
>> Pavel
>>
>> On Thu, Dec 31, 2009 at 3:23 PM, Pavel <pa...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm looking for the way to filter out control characters prohibited
>>> by XML
>>> spec at/after marshalling. Otherwise consumers are unable to
>>> unmarshal the
>>> content.
>>>
>>> Is there an out of the box means for doing that? If not, can you
>>> recommend
>>> the right way for doing that?
>>>
>>> I just did similar exercise with CXF, there it was took creating custom
>>> XMLStreamWriter and using outbound interceptor to replace original
>>> writer
>>> with custom one.
>>>
>>> Thanks,
>>> Pavel
>>>
>>
>
>
Re: JAXB marshaller & control characters
Posted by Willem Jiang <wi...@gmail.com>.
Hi,
I think you can write a type converter[1] which can turn the InputStream
to a JAXB safe (which filters the control characters) InputStream.
Then can define your route like this
from("direct:start").covertTo(JaxbSafeInputStream.class).unmarshal(new
JaxbDataFormat("org.apache.camel.example")).to("mock:endpoint");
If so I'd like to integrate it into camel-jaxb :)
[1] http://camel.apache.org/type-converter.html
Willem
Pavel wrote:
> I found a few relevant links:
>
> http://old.nabble.com/UTF-8-characters-jaxb-td25531336.html#a25531336
> http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char
>
> Seems like this topic was discussed already, but I'm not if relevant
> replacement mechanism made it into camel.
>
> Pavel
>
> On Thu, Dec 31, 2009 at 3:23 PM, Pavel <pa...@gmail.com> wrote:
>
>> Hi,
>>
>> I'm looking for the way to filter out control characters prohibited by XML
>> spec at/after marshalling. Otherwise consumers are unable to unmarshal the
>> content.
>>
>> Is there an out of the box means for doing that? If not, can you recommend
>> the right way for doing that?
>>
>> I just did similar exercise with CXF, there it was took creating custom
>> XMLStreamWriter and using outbound interceptor to replace original writer
>> with custom one.
>>
>> Thanks,
>> Pavel
>>
>
Re: JAXB marshaller & control characters
Posted by Pavel <pa...@gmail.com>.
I found a few relevant links:
http://old.nabble.com/UTF-8-characters-jaxb-td25531336.html#a25531336
http://www.w3.org/TR/2004/REC-xml-20040204/#NT-Char
Seems like this topic was discussed already, but I'm not if relevant
replacement mechanism made it into camel.
Pavel
On Thu, Dec 31, 2009 at 3:23 PM, Pavel <pa...@gmail.com> wrote:
> Hi,
>
> I'm looking for the way to filter out control characters prohibited by XML
> spec at/after marshalling. Otherwise consumers are unable to unmarshal the
> content.
>
> Is there an out of the box means for doing that? If not, can you recommend
> the right way for doing that?
>
> I just did similar exercise with CXF, there it was took creating custom
> XMLStreamWriter and using outbound interceptor to replace original writer
> with custom one.
>
> Thanks,
> Pavel
>