>>> 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()
FYI:
This discussion received no further development.
Alex
>
> 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
>
>
>
>