Do we really need the generate parameter in the ProcessorType?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Do we really need the generate parameter in the ProcessorType?

Willem.Jiang
Administrator
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?

Willem
Reply | Threaded
Open this post in threaded view
|

Re: Do we really need the generate parameter in the ProcessorType?

jstrachan
2008/12/10 Willem Jiang <[hidden email]>:

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

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/
Reply | Threaded
Open this post in threaded view
|

Re: Do we really need the generate parameter in the ProcessorType?

Willem.Jiang
Administrator
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 <[hidden email]>:
>> 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.
>