>> 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.
introducing Part.getFile() is a good idea. I think that I'd suggest the following
definition to make the behaviour more strict and portable
/**
* @return java.io.File object pointing to a file saved using write(String)
*
* @throws IllegalStateException - is thrown if write(String) method was not called.
*/
public java.io.File getFile() throws IllegalStateException {...}
Alex
>
> 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.
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
>