Hi James, Thanks for your explanation, I saw the issue by trying to remove the generate parameter. Now we still need it to provide a DSL friendly fluent API. But I find a small issue[1] of the processors, I did a quick clean work on it, and very thing look good.
[1] https://issues.apache.org/activemq/browse/CAMEL-1180 Willem James Strachan wrote: > 2008/12/10 Willem Jiang <[EMAIL PROTECTED]>: >> Hi, >> >> When I start to work on CAMEL-1171, I found that we don't need to use >> the <Type extends ProcessorType> in the ProcessorType class definition. >> >> public abstract class ProcessorType<Type extends ProcessorType> extends >> OptionalIdentifiedType<Type> implements Block >> >> For the common usecase to() method, it just need to return a >> ProcessorType, I don't think we will call the >> setParallelProcessing(true) after that, if we create a MulticastType first. >> >> Just like this >> >> from("direct:start").multicast().setParallelProcessing(true)... >> to("direct:endpointA").to("direct:endpointB"); >> >> we won't write the rule like this >> from("direct:start").multicast()... >> to("direct:endpointA").setParallelProcessing(true).to("direct:endpointB"); >> >> Now , I just have a question about the OptionalIdentifiedType, since I >> never use it. I don't know when we will call the >> OptionalIdentifiedType's description method. >> Can we just change the ProcessorType definition like this ? >> >> public abstract class ProcessorType extends >> OptionalIdentifiedType<ProcessorType> implements Block >> >> Is they something that I'm missing? > > The generics use is kinda complex in the DSL - if you try remove stuff > like this you'll probably be surprised by what breaks :). > > One of the main reasons for it being there is AFAIK to allow derived > classes to return the derived type in blocks. e.g. try remove it and > see if the choice()/when()/otherwise() stuff still compiles. See how > the parameterized Type is returned by to() or filter() etc. > > The generics compiler in Java is a bit pants in that it only tries so > far to resolve generic types and just defaults to Object after a > while; so we've gotta be careful using them - but they can be useful > in the DSL. >
