camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen" ...@silverbullet.dk>
Subject RE: Problem with FileEndpoint
Date Tue, 14 Oct 2008 06:31:45 GMT
Hi

Thanks a lot for the sample. I will look into it this week/weekend.


Yeah there is a refactor planned for Camel 2.0 to remove generics in Exchange and other areas
as well. Then all the different message types should be reduced, and the API should be easier
to work with:
http://activemq.apache.org/camel/camel-20-design.html

Feedback for the 2.0 design is much welcome.


File as an InputStream, well have java.io.File allows you to access this handle and get File
related information as well. Storing only a InputStream you loose this. You can always do
the convertions from File -> InputStream with

from("file://bla").convertBodyTo(InputStream.class).to("bean:doSomething");


And the same technique can be used for reading the file content at once as you also suggested
previously:

from("file://bla").convertBodyTo(String.class).to("bean:doSomething");

 

Med venlig hilsen
 
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk

-----Original Message-----
From: Christian Schneider [mailto:chris@die-schneider.net] 
Sent: 14. oktober 2008 00:52
To: camel-user@activemq.apache.org
Subject: Re: Problem with FileEndpoint

Hi Claus,

I have added my example project to the issue.

About the FileMessage. I understand that large files are important but 
wouldn´t it be better to put an InputStream into the message. In this 
case it would be an InputStream from a file but the concept is much more 
general than transmitting a File object. For a JMS message you could use 
an InputStream from the message content. Both quite different cases 
could be handled with the same message type.

I would even make the assumption that Camel could live with just one 
message class that allows to store Streams for binary data, 
Readers/Writers for textual data and Objects. Together with the 
properties this could be flexible enough for all cases.

All the different message types are just making things quite complex.

Greetings

Christian

Claus Ibsen schrieb:
> Hi
>
> Thanks for the workaround.
>
> I would still however like to investigate the bug. I will create a ticket for it.
>
> Some end-users need to access the java.io.File and not read the content into memory as
they need to work on the file stream instead. Some end-users reads 1gb CSV files etc.
>
> So it should work in all situations. 
>
>
>
> Med venlig hilsen
>  
> Claus Ibsen
>   

-- 

Christian Schneider
---
http://www.liquid-reality.de


Mime
View raw message