You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Martin Cooper <ma...@apache.org> on 2003/05/06 02:33:04 UTC
Re: [FileUpload] The getName method yields inconsist value
"Vernon" <ve...@gatewaytech.com> wrote in message
news:oprop4o8sxvu4si3@mail.bluesoft.ca...
>
> I just find the method returns a file name with Opera 10.7 and a full path
> of a file with IE 5.0. I would like to confirm that is not a desired
> behaviour. The version of the fileupload package I use is 1.0-dev, build
> 05-03. I use a newer API: DiskFileUpload. I don't see any stable build
with
> the API other than a night build.
FileUpload is giving you the file name as the browser provided it, so the
fact that you are seeing different behaviour across browsers is because the
browsers themselves behave differently in this regard. The file upload spec
(RFC 1867) is silent on this.
The DiskFileUpload API is the right one to use. It was recently added, but
will become part of Beta 2 as soon as I can get that done.
>
> Also, how to use the new write method with attribute file? I can't see how
> a file instance can be constructed within the content.
I'm not sure I understand what you mean. 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.
--
Martin Cooper
>
> --
> Vernon
Re: [FileUpload] The getName method yields inconsist value
Posted by Vernon <ve...@gatewaytech.com>.
1) The forward slashes in the path are generated either by a method like
request.getSession().getServletContext()
.getRealPath(request.getServletPath());
or File.separator/System.getProperty("file.separator"). In other words,
they are based on the system itself. Sure, I can have the following code to
insert a forward slash in front of forward slash. But, I don't think it is
favorable by any standard.
int i=0;
while((i = src.indexOf("\\", i)) >= 0) {
src = src.substring(0, i) + "\\" + src.substring(i);
i += 2;
}
2) The exception is thrown AFTER a file is uploaded. That means the write
method knows how to find the path and does it correctly. I don't see any
reason the exception shall be thrown in the situation.
Vernon
On Sat, 10 May 2003 02:17:59 -0400, Rob Leland <rl...@apache.org> wrote:
> The \ is considered an escape for control characters,
> if you want '\' you need '\\'
>
> So for "E:\Tomcat\Tomcat 4.1\webapps\mm\client/photo\Tom\dog1.gif"
> have you tried: ;
> "E:\\Tomca\\Tomcat 4.1\\webapps\\mm\\client/photo\\Tom\\dog1.gif"
>
> -Rob
>
> Vernon wrote:
>
>> 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. 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
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
--
Vernon
Re: [FileUpload] The getName method yields inconsist value
Posted by Rob Leland <rl...@apache.org>.
The \ is considered an escape for control characters,
if you want '\' you need '\\'
So for "E:\Tomcat\Tomcat 4.1\webapps\mm\client/photo\Tom\dog1.gif"
have you tried: ;
"E:\\Tomca\\Tomcat 4.1\\webapps\\mm\\client/photo\\Tom\\dog1.gif"
-Rob
Vernon wrote:
> 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. 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
Re: [FileUpload] The getName method yields inconsist value
Posted by Vernon <ve...@gatewaytech.com>.
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 <ma...@apache.org>
wrote:
>
> "Vernon" <ve...@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 <ma...@apache.org>
>> wrote:
>>
>> >
>> > "Vernon" <ve...@gatewaytech.com> wrote in message
>> > news:oproru03ozvu4si3@mail.bluesoft.ca...
>> >> On Tue, 6 May 2003 07:54:10 -0700 (PDT), Martin Cooper
>> > <ma...@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
Re: [FileUpload] The getName method yields inconsist value
Posted by Martin Cooper <ma...@apache.org>.
"Vernon" <ve...@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 <ma...@apache.org>
> wrote:
>
> >
> > "Vernon" <ve...@gatewaytech.com> wrote in message
> > news:oproru03ozvu4si3@mail.bluesoft.ca...
> >> On Tue, 6 May 2003 07:54:10 -0700 (PDT), Martin Cooper
> > <ma...@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
Re: [FileUpload] The getName method yields inconsist value
Posted by Vernon <ve...@gatewaytech.com>.
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. 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 <ma...@apache.org>
wrote:
>
> "Vernon" <ve...@gatewaytech.com> wrote in message
> news:oproru03ozvu4si3@mail.bluesoft.ca...
>> On Tue, 6 May 2003 07:54:10 -0700 (PDT), Martin Cooper
> <ma...@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
Re: [FileUpload] The getName method yields inconsist value
Posted by Martin Cooper <ma...@apache.org>.
"Vernon" <ve...@gatewaytech.com> wrote in message
news:oproru03ozvu4si3@mail.bluesoft.ca...
> On Tue, 6 May 2003 07:54:10 -0700 (PDT), Martin Cooper
<ma...@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
Re: [FileUpload] The getName method yields inconsist value
Posted by Vernon <ve...@gatewaytech.com>.
On Tue, 6 May 2003 07:54:10 -0700 (PDT), Martin Cooper <ma...@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.
> --
> Martin Cooper
>
Vernon
--
Vernon
Re: [FileUpload] The getName method yields inconsist value
Posted by Martin Cooper <ma...@apache.org>.
On Mon, 5 May 2003, Vernon wrote:
> Hi, Martin,
>
> On Mon, 5 May 2003 17:33:04 -0700, Martin Cooper <ma...@apache.org>
> wrote:
>
> > FileUpload is giving you the file name as the browser provided it, so the
> > fact that you are seeing different behaviour across browsers is because
> > the
> > browsers themselves behave differently in this regard. The file upload
> > spec
> > (RFC 1867) is silent on this.
> >
>
> I hope this information will be in the API documentation soon so that
> others will deal with this kind of difference themselve, and won't spend
> hours messed around like I did. I luckly test the code on two browsers in
> the very early stage.
I can add it to the JavaDocs.
>
> > The DiskFileUpload API is the right one to use. It was recently added,
> > but
> > will become part of Beta 2 as soon as I can get that done.
> >
> >>
> >> Also, how to use the new write method with attribute file? I can't see
> >> how
> >> a file instance can be constructed within the content.
> >
> > I'm not sure I understand what you mean. 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.
;-)
--
Martin Cooper
>
> Talking about "mess with separators", the lastIndexOfSeparator at (1)
> doesn't return a positive value while a file separator does show up in a
> file name in the following code segment. I have to add the code on (2) to
> get the file name (without path) in a Window OS.
>
> // ...
> fileName = fi.getName();
> int lastIndexOfSeparator = fileName.lastIndexOf(File.separator); (1)
> if(lastIndexOfSeparator == -1) (2)
> lastIndexOfSeparator = fileName.lastIndexOf("\\");
> if(lastIndexOfSeparator != -1)
> fileName = fileName.substring(lastIndexOfSeparator + 1);
> > --
> > Martin Cooper
> >
> >
>
> Thanks very much for your quick response and helpful information.
>
> Vernon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
Re: [FileUpload] The getName method yields inconsist value
Posted by Vernon <ve...@gatewaytech.com>.
Hi, Martin,
On Mon, 5 May 2003 17:33:04 -0700, Martin Cooper <ma...@apache.org>
wrote:
> FileUpload is giving you the file name as the browser provided it, so the
> fact that you are seeing different behaviour across browsers is because
> the
> browsers themselves behave differently in this regard. The file upload
> spec
> (RFC 1867) is silent on this.
>
I hope this information will be in the API documentation soon so that
others will deal with this kind of difference themselve, and won't spend
hours messed around like I did. I luckly test the code on two browsers in
the very early stage.
> The DiskFileUpload API is the right one to use. It was recently added,
> but
> will become part of Beta 2 as soon as I can get that done.
>
>>
>> Also, how to use the new write method with attribute file? I can't see
>> how
>> a file instance can be constructed within the content.
>
> I'm not sure I understand what you mean. 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.
Talking about "mess with separators", the lastIndexOfSeparator at (1)
doesn't return a positive value while a file separator does show up in a
file name in the following code segment. I have to add the code on (2) to
get the file name (without path) in a Window OS.
// ...
fileName = fi.getName();
int lastIndexOfSeparator = fileName.lastIndexOf(File.separator); (1)
if(lastIndexOfSeparator == -1) (2)
lastIndexOfSeparator = fileName.lastIndexOf("\\");
if(lastIndexOfSeparator != -1)
fileName = fileName.substring(lastIndexOfSeparator + 1);
> --
> Martin Cooper
>
>
Thanks very much for your quick response and helpful information.
Vernon