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 <[email protected]>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 <[email protected]> >> 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 <[email protected] <mailto: >>>> [email protected]>> 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 >>>> <[email protected] <mailto:[email protected]>> 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 >>>> >>>> >>>> ... >>>> >>>> >>> >> >> >
