On 29 March 2017 at 19:18, Edward Burns <edward.burns_at_oracle.com> wrote:
EB> Greg, what say you to this?
>>>>> On Wed, 29 Mar 2017 20:58:15 +1100, Greg Wilkins <gregw_at_webtide.com> said:
GW> I'm cool with all that - I'm not wanting to break any existing
GW> interpretations and just really want javadoc clarified.
MT> @param fileName The location into which the uploaded part should
MT> be stored. file names and relative paths are
MT> relative to {_at_link
MT> javax.servlet.MultipartConfigElement#getLocation()}.
MT> Absolute paths are used as provided.
MT> Note: that this is a system dependent string and URI
MT> notation may not be acceptable on all systems. For
MT> portability, this string should be generated with the
MT> File or Path APIs.
EB> Mark, thanks for your concise suggestion. In the spirit of compromise,
EB> I vote to accept Mark's proposal here.
GW> That works for me. However one quibble is that "file names and relative
GW> paths are relative to ..." is overly verbose. It can just be "Relative
GW> paths are relative to ..."
Well, the choice to use "file names and relative paths" was a nod to
your question of whether or not the fileName argument can contain a path
or must it just be a filename. I will go with this:
@param fileName The location into which the uploaded part should
be stored. The value may be a file name or a path. The actual
location of the file in the filesystem is relative to {_at_link
javax.servlet.MultipartConfigElement#getLocation()}. Absolute
paths are used as provided and are relative to
<code>getLocation()</code>. Note: that this is a system
dependent string and URI notation may not be acceptable on all
systems. For portability, this string should be generated with
the File or Path APIs.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 16 business days until planned start of Servlet 4.0 Public Review