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
As for the absolute path - I think it is fine that we have it relative
to the MultipartConfig location attribute. In the MR that we did for
Servlet 3.0 we clarified the location attribute as following -
Clarify that "location" attribute
ofjavax.servlet.annotation.MultipartConfigand the location element of
<multipart-config> is interpreted as an absolute path and defaults to
the value of the "javax.servlet.context.tempdir". If a relative path is
specified, it will be relative to thetempdirlocation. The test for
absolute pathvsrelative path must be done viajava.io.File.isAbsolute
- Rajiv
On 7/19/11 2:36 PM, Alex Rojkov 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.
> 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.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>