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 >> >> >> ... >> > > -- Best regards, Pavel
