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> 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>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 >>> >>> >>> ...
