camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: [Discuss] Remove generics and special message from file component
Date Thu, 01 Sep 2011 09:05:14 GMT
Am 31.08.2011 21:34, schrieb Claus Ibsen:
> On Wed, Aug 31, 2011 at 3:28 PM, Christian Schneider
> <>  wrote:
> Frankly by introducing WrappedFile in the root package, which is, 
> according to you, a temporary solution, is a bad idea. You now add 
> more confusion to the mix. Just because a structure 101 diagram should 
> have one less arrow less. Instead you end up pushing more and more to 
> the root package, and make it more and more general. Abstract over 
> abstraction :( 
It is not about a line in an architecture tool. It is about making the 
file component independent of the rest of camel. The disadvantage of 
having the  file component in camel-core is that people do not really 
have an eye on dependencies.

In my point of view there should be two architectural rules for components:
1) A component should only know about the camel-api
2) The camel-core as well as camel-api  should not know about the 
component at all

So the fact the GwericFile was used in camel-core outside of the file 
component means that rule 2 is not followed. Btw. if the component is a 
separate project this can not happen so easily. So what I did with 
WrappedFile is create an interface that makes the file component more 
compliant to rule 2 again. The WrappedFile abstraction can be removed 
again as soon as the file component simply transports File objects or 
other well known objects. Transporting private classes of the component 
is the real bad thing.

There are two violations of rule 1 that are not yet solved for the file 
component. CorePackageScanClassResolver and ToStringTypeConverter from 
impl.converter still use GenericFile and GenericFileConverter. I will 
try to resolve this too.

Btw. I just digged a bit deeper into the dependencies of the file 
component to see how far away from following rule 1 we are right now. 
Currently the file component still uses 10 impl classes and 
converter.IOConverter as well as processor.MemoryIdempotentRepository. 
These will also require quite a lot of work.

So again this should not be any insult against anyone in our fine 
community. We do not yet have the above rules about components. So no 
one can be blamed for not following them. I just try to clean things up 
and on the way I try to figure out what could be good rules for the 
future. At a later time I will propose the rules on the dev list so we 
can make them official if they make sense. It all comes down to bring 
camel into a state that allows further growth and allows to react on new 
requirements in the same fast pace that we had in the past. If we do not 
clean up and create those rules camel will soon be very difficult to 
change and will not be able to grow as well as it did in the past.

> So to re-iterate my thoughts. Keep the 2.x as is. Consider changes for 
> Camel 3.0 if it makes sense and is feasible. 
Absolutely. Removing the generics is only an option for the 3.x release.


Christian Schneider

Open Source Architect
Talend Application Integration Division

View raw message