commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vernon <vern...@gatewaytech.com>
Subject Re: [FileUpload] The getName method yields inconsist value
Date Sat, 10 May 2003 22:20:43 GMT

You're right, Martin. The exception is not from the write method. I ignored 
the fact, a sumbit button also is a form field. So nothing is wrong with 
the write method.


On Sat, 10 May 2003 09:28:10 -0700, Martin Cooper <martinc@apache.org> 
wrote:

>
> "Vernon" <vernonw@gatewaytech.com> wrote in message
> news:oproxxjqzevu4si3@mail.bluesoft.ca...
>> Hi, Martin,
>>
>> Thanks again for your detailed explanation.
>>
>> I shouldn't ask a question when I was very tired. The question is not
>> right.
>>
>> In the follow-up procedure, I run into the following exception:
>>
>> java.lang.Exception: File name is invalid
>>
>> on the line of write method although the file is written in the desired
>> directory.
>
> A stack trace would be helpful, or at least *which* line of the write()
> method.
>
> --
> Martin Cooper
>
>
>> I have tried the both write(String) and write(File) methods and
>> yields the same exception. The file path is "E:\Tomcat\Tomcat
>> 4.1\webapps\mm\client/photo\Tom\dog1.gif" as the input parameter for
>> write(String). Is the exception thrown due to the backward slash? If so,
>> how I shall deal with path informaion stored in web.xml file? The 
>> portion,
>> "client/photo", of the path is in the xml file.
>>
>> Vernon
>>
>>
>> On Tue, 6 May 2003 15:53:29 -0700, Martin Cooper <martinc@apache.org>
>> wrote:
>>
>> >
>> > "Vernon" <vernonw@gatewaytech.com> wrote in message
>> > news:oproru03ozvu4si3@mail.bluesoft.ca...
>> >> On Tue, 6 May 2003 07:54:10 -0700 (PDT), Martin Cooper
>> > <martinc@apache.org>
>> >> wrote:
>> >>
>> >> >> > If you had this before:
>> >> >> >
>> >> >> > String newFile = "C:\\temp\\upload.dat";
>> >> >> > item.write(newFile);
>> >> >> >
>> >> >> > you would just do this now:
>> >> >> >
>> >> >> > File newFile = new File("C:\\temp\\upload.dat");
>> >> >> > item.write(newFile);
>> >> >> >
>> >> >> > Passing a File to write() allows you to do the same as you
would
>> >> have
>> >> >> > done
>> >> >> > before, but it also allows you to work with paths and files
> without
>> >> >> > having
>> >> >> > to mess with separators, amongst other things.
>> >> >> >
>> >> >>
>> >> >> So what is the reason(s) the write(String) API is deprecated? It

>> is
>> >> >> discouraged to use a deprecated method, is it? Also, it is 
>> difficult
>> >> to
>> >> >> use
>> >> >> the write(File) method if the getName() method only return a file
>> >> name
>> >> >> only, but not its full path.
>> >> >
>> >> > Yes, the use of deprecated methods is discouraged, because those
>> >> methods
>> >> > will go away in a later release (in this case, RC1). I deprecated 
>> the
>> >> > write(String) method because you can accomplish the same thing - 
>> and
> a
>> >> > lot
>> >> > more - with write(File).
>> >> >
>> >> > You absolutely should *not* be using the path provided by getName()
> to
>> >> > pass to write(). That path is the one to the original file, on the
>> >> > browser
>> >> > user's system, ans bears no relationship to the file system the
>> > container
>> >> > is using. Attempting to use this path would be *very* dangerous.
>> >> >
>> >> > This looks like an excellent reason to remove the write(String)
>> >> method.
>> >> > ;-)
>> >> >
>> >>
>> >> So, how to create a file instance as you stated above without a file
>> >> path
>> >> information? It isn't a method of FileItem returning a file full 
>> path.
>> >
>> > OK, let's go back to basics. Once you have parsed the upload, you are
>> > iterating over the file items and you come across a file upload. You
> want
>> > to
>> > copy/move the uploaded data to some more permanent location, so you 
>> need
>> > to
>> > call write() with a File instance.
>> >
>> > You create the File instance the same way you would create an output
> file
>> > for any other file i/o operation. I gave an example in an earlier
> message
>> > in
>> > this thread, but using a single fully qualified path (see above). But
> for
>> > another example, let's suppose that you have some data store that you
>> > want
>> > to move the uploaded file to. Just for the sake of the example we'll
>> > construct a File for that directory, and then make up a name for the 
>> new
>> > file.
>> >
>> > File dataStore = new File("X:\\VernonsDataStore\\");
>> > String fileName = "SomeFileName.dat";
>> > File outputFile = new File(dataStore, fileName);
>> > item.write(outputFile);
>> >
>> > I've expanded this for the sake of illustration, but you can do this
>> > however
>> > you want. If you wanted your data store to be in a subdirectory of the
>> > system temp directory you could do this:
>> >
>> > String systemTempDir = System.getProperty("java.io.tmpdir");
>> > File dataStore = new File(systemTempDir, "VernonsDataStore");
>> > String fileName = "SomeFileName.dat";
>> > File outputFile = new File(dataStore, fileName);
>> > item.write(outputFile);
>> >
>> > This is just the normal usage of File objects for file i/o - there's
>> > nothing
>> > special about it because it's an uploaded file.
>> >
>> > If all you wanted to do was access the uploaded data, of course, you
>> > would
>> > just use getInputStream() and process it however you want.
>> >
>> > If there is some reason you need to access the original temp file
> created
>> > by
>> > FileUpload, and you are using DiskFileUpload, and you are not 
>> supplying
>> > your
>> > own factory, then you can do this:
>> >
>> > File originalUpload = ((DefaultFileItem)item).getStoreLocation();
>> >
>> > but there is no good reason to do this when you can use write() or
>> > getInputStream() instead, and be free of the implementation details of
>> > DiskFileUpload.
>> >
>> > If you haven't done so already, I recommend you take a look at the new
>> > documentation on the FileUpload web site. It should cover everything 
>> you
>> > need.
>> >
>> > --
>> > Martin Cooper
>> >
>> >
>> >>
>> >> > --
>> >> > Martin Cooper
>> >> >
>> >>
>> >> Vernon
>> >>
>> >>
>> >>
>> >> -- Vernon
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
>> >
>> >
>>
>>
>>
>> -- Vernon
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>



-- 
Vernon

Mime
View raw message