On 26/07/2011 21:20, Alex Rojkov wrote:
>> I think it should be fine adding this method to Part. Maybe instead of catching the IllegalStateException and then retrying we could also add another method to Part to check if the file has been written
>>
>> boolean Part.isWritten
>
> Re-reading the thread: does that make the following outcome of the getFile possible in case where implementation uses temp storage?
>
> {
> part.getFile(); // returns /tmp/abcd.dat (it's a temporary file)
> part.write("/data/my-movie.avi");
> part.getFile(); // returns /data/my-movie.avi
> }
The latest suggestion was that the first call to part.getFile() would
throw an IllegalStateException if part.write() has not been called. On
reflection, I am happy with that. My thinking about providing access to
the temporary file was around performance but there are other ways to
handle that with the current API.
I'd be happy with adding Part.getFile() and Part.isWritten()
However, I still think there is a case for Part.write() optionally
taking an absolute path. Consider the case where an application needs to
upload files to two different parts of the file system (e.g.
/usr/local/jira/jira-data and /x1/jira/attachments). If Part.write() is
constrained to being relative to the MultipartConfig.location then that
location has to be the common root of both locations which in this case
is /.
It is possible to handle this by setting MultipartConfig.location to /
but that feels like a slightly clunky work-around. Allowing absolute
paths is neater.
Mark