On Fri, Jan 8, 2010 at 7:38 PM, Stephen Gargan <steve.gar...@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 <willem.ji...@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 >>> <willem.ji...@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 <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 >>>>>>> >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> >>>>> >>> >> >> > -- 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
