You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Christian Schneider <ch...@die-schneider.net> on 2011/08/31 15:28:33 UTC
[Discuss] Remove generics and special message from file component
Currently the file component uses a special message GenericFile to send
files into camel routes.
This is bad as several other parts of camel need to deal with this type.
It is already a bit better now that I introduced WrappedFile as an
abstraction of GenericFile so other parts of camel do not have to know
details about the file component.
The big question is though can we get rid of this completely?
So my proposal is:
- Send files as File objects in the body of a regular DefaultMessage. We
could also think about sending a FileInputStream
- Send other details as headers
- Also get rid of FileBinding
So what are your thoughts about that?
Christian
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [Discuss] Remove generics and special message from file component
Posted by Christian Schneider <ch...@die-schneider.net>.
Am 31.08.2011 21:34, schrieb Claus Ibsen:
> On Wed, Aug 31, 2011 at 3:28 PM, Christian Schneider
> <ch...@die-schneider.net> 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
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [Discuss] Remove generics and special message from file component
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Claus,
I first did not see the connection to camel-ftp. I now see that it is
necessary at the moment. I think there are simpler solutions though.
I will work out a proposal. Of coure this is not for camel 2.x. The
change would be too big.
Christian
Am 31.08.2011 21:34, schrieb Claus Ibsen:
> On Wed, Aug 31, 2011 at 3:28 PM, Christian Schneider
> <ch...@die-schneider.net> wrote:
>> Currently the file component uses a special message GenericFile to send
>> files into camel routes.
>> This is bad as several other parts of camel need to deal with this type. It
>> is already a bit better now that I introduced WrappedFile as an abstraction
>> of GenericFile so other parts of camel do not have to know details about the
>> file component.
>>
> This is not bad as its an abstract the component offered. So if you
> use file/ftp/xxx you would have that GenericFile at your disposal.
> Now the Camel type converters would make it easy to get a java.io.File
> (if its a file component), a InputStream (which is what the ftp
> components offers), or some X other object that contains access to the
> underlying file implementation.
>
> 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 :(
>
>
>> The big question is though can we get rid of this completely?
>>
>> So my proposal is:
>>
>> - Send files as File objects in the body of a regular DefaultMessage. We
>> could also think about sending a FileInputStream
>> - Send other details as headers
>> - Also get rid of FileBinding
>>
>> So what are your thoughts about that?
>>
> Camel 2.x should be kept backwards compatible and API stable.
> We have end users who build custom components on top of the Camel file
> component and rely on the API being as is.
>
> The camel-ftp component is built on top of the file component and the
> generics help making this possible.
>
> Back in the days when the file component was created for camel 2.0, it
> was meant to be a building block for file based components such as
> - ftp
> - commons-vfs
> - a webdav component
>
> It still makes sense to have it as a base component for file based
> components. Today commons-vfs is a dead project. But we frankly still
> miss a webdav component.
>
>
>
> For Camel 3.0 we may consider adjusting pieces of it, if it makes sense.
>
> 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.
>
>
>
>> Christian
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [Discuss] Remove generics and special message from file component
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Comments inline,
Hadrian
On 08/31/2011 03:34 PM, Claus Ibsen wrote:
>> So what are your thoughts about that?
>> >
> Camel 2.x should be kept backwards compatible and API stable.
> We have end users who build custom components on top of the Camel file
> component and rely on the API being as is.
That is only true for APIs consumed by users (both kinds: end users and
component writers). It is much less relevant for code we consume ourselves.
> The camel-ftp component is built on top of the file component and the
> generics help making this possible.
And there are other ways to handle that.
> Back in the days when the file component was created for camel 2.0, it
> was meant to be a building block for file based components such as
> - ftp
> - commons-vfs
> - a webdav component
> It still makes sense to have it as a base component for file based
> components. Today commons-vfs is a dead project. But we frankly still
> miss a webdav component.
Unfortunately true for commons-vfs, and it doesn't look like it'll be
revived from what I could get.
> For Camel 3.0 we may consider adjusting pieces of it, if it makes sense.
>
> 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.
Christian, what about leaving this for 3.0? I agree it needs to be done
and it's certainly feasible, but I am not sure it's that urgent.
Hadrian
Re: [Discuss] Remove generics and special message from file component
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Aug 31, 2011 at 3:28 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> Currently the file component uses a special message GenericFile to send
> files into camel routes.
> This is bad as several other parts of camel need to deal with this type. It
> is already a bit better now that I introduced WrappedFile as an abstraction
> of GenericFile so other parts of camel do not have to know details about the
> file component.
>
This is not bad as its an abstract the component offered. So if you
use file/ftp/xxx you would have that GenericFile at your disposal.
Now the Camel type converters would make it easy to get a java.io.File
(if its a file component), a InputStream (which is what the ftp
components offers), or some X other object that contains access to the
underlying file implementation.
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 :(
> The big question is though can we get rid of this completely?
>
> So my proposal is:
>
> - Send files as File objects in the body of a regular DefaultMessage. We
> could also think about sending a FileInputStream
> - Send other details as headers
> - Also get rid of FileBinding
>
> So what are your thoughts about that?
>
Camel 2.x should be kept backwards compatible and API stable.
We have end users who build custom components on top of the Camel file
component and rely on the API being as is.
The camel-ftp component is built on top of the file component and the
generics help making this possible.
Back in the days when the file component was created for camel 2.0, it
was meant to be a building block for file based components such as
- ftp
- commons-vfs
- a webdav component
It still makes sense to have it as a base component for file based
components. Today commons-vfs is a dead project. But we frankly still
miss a webdav component.
For Camel 3.0 we may consider adjusting pieces of it, if it makes sense.
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.
> Christian
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/