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.ji...@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 <pag...@gmail.com <mailto:
pag...@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.ji...@gmail.com <mailto:willem.ji...@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
...
