On 18/07/2011 16:37, Ted Goddard wrote:
>
> An absolute path doesn't entirely solve the problem -- the application might
> want to make use of the MultipartConfig-specified location at deployment time,
> but might also want to know where the file was written.
>
> The option for an absolute path is useful, but should be covered by the spec. Currently
> the JavaDoc says:
>
> fileName - the name of the file to which the stream will be written. The file is created relative to the location as specified in the MultipartConfig
>
> Which could be interpreted as always prepend the "location" no matter what the
> structure of the fileName.
Indeed. Bending the spec that way seemed the easiest way of providing
users with some flexibility without breaking the API.
+1 to the spec explicitly allowing absolute paths here. Yes it allows
apps to write files anywhere (not good) but if you don't trust the app
run it under a security manager and limit where it can write files.
In terms of returning the File, I'd be happy with Part.getFile(). There
are some options for exactly what that returns. I'd suggest:
- If Part.write() has been called, return the resulting file
- If Part.write() has not been called and a temporary file is available
(implementation dependent), return that
- else return null
Mark
>
> Ted.
>
> On 2011-07-16, at 7:22 AM, Mark Thomas wrote:
>
>> On 15/07/2011 21:46, Ted Goddard wrote:
>>>
>>> On javax.servlet.http.Part we currently have the method
>>>
>>> void write(java.lang.String fileName)
>>>
>>> but it's not easy for application code to get to the written file
>>> because MultipartConfig.location can be modified at deployment time.
>>
>> Tomcat allows fileName to be absolute. Only if it is relative is
>> MultipartConfig.location used. Does that solve the problem?
>>
>> Mark
>>
>>> Perhaps the easiest thing would be to have the written File returned:
>>>
>>> java.io.File write(java.lang.String fileName)
>>>
>>> or add Part.getFile() (which could return null if the file has not been
>>> written -- the interface does seem to allow multipart uploads that are not
>>> stored immediately on the file system; do any implementations work this way?)
>>
>>
>>>
>>> Cheers,
>>> Ted.
>>>
>>>
>>
>>
>>
>
>