ByteArrayStream is what we are using now, but I am concerned about the memory consumption since we are planning for large files with video content. It might be that we have to implement an intermediate file storage then to avoid memory issues.
Thanks for the feedback. Tore Hi! > mobic.com [mailto:[EMAIL PROTECTED] wrote > > > I must admit that I have not studied the implementation of MINA ftp in > detail, so I will rather describe our need. > > Our intent is to store a file as a blob directly in a database, not > using > the file system. A very quick implementation is this one line code: > > Hibernate.createBlob(inputstream) > > This requires access to the data as an inputstream. The most simple solution would be to fetch the bytes of the File you get, put them in an array and the array in a ByteArrayInputStream, so you get your InputStream, without needing access to the underlying IO implementation. > To get access to the stream we have created our own STOR command, and > we > then have to convert the outputstream to an inputstream to be able to > use > the Hibernate util. I don't think a simple passthrough will get you what you want, because (As far as I remember), the Hibernate util try to read all bytes from the inputstream, it get. So as long as your connection is open, the Hibernate util won't return, because the IO-InputStream always says "There's more data, just wait" until connection is closed. > With the current implementation of the IODataConnection it seams very > simple > to get access to the inputstream. If you intent to change the design > this > might be another case. If so, please evaluate our need and implement a > proper solution. Store data directly into a database will be a very > important usage of an embedded MINA ftp server. Yes, I will have to do a similar solution in the next time. But If design have to be broken for my solution, I would first question my solution and then the design > Please tell if you have better ways of using MINAftp for storing files > directly into a database. HTH Steve
