This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
Because my responseReader.readLine() method fails when it is an XL file (gives an error), so I was trying to replace the code and use FileReader instead.
So, I modified the code as follows -
But I am always getting a FileNotFoundException. When I debug the value of "file" object = "http:/devo.mim.com.au:3333/fetch/:1715327", which is incorrect as the "file" object should have been "http://devo.mim.com.au:3333/fetch/:1715327".
Somehow the double forward slash has been converted to a single forward slash.
I had tried to modify the sourceFileURL as follows -
The sourceURL would give me a correct value which is where the document exists "http://devo.mim.com.au:3333/fetch/:1715327", but as soon as the object file was created using the File constructor which takes string as a parameter, File file = new File(sourceFileURL) it would give an incorrect value of "http:/devo.mim.com.au:3333/fetch/:1715327" and so throw a FileNotFoundException.
I also tried to modify the file constructor with various options as follows but none of them has helped me.
File cannot work with http:// "files". It can only work with files on your local system (hard disks, floppy disks, cds, USB sticks, etc) and in Windows on file shares. You need java.net.URL with URLConnection and the latter's openStream() method.
Thanks a lot Rob for your prompt reply. It really helped me a lot!!! And made me realize that file can only work with local files.
Just another quick question in relation to my previous question.
My previous code was using the java.net and the URL, HttpURLConnection and doing a readLine on the BufferedReader to read the remote file, but the readLine() has been returning me an error upon encountering an XL file, which is why I was thinking of using a FileReader. Can you please advise me why was that happening, and how do I make the code read a remote "XL" file? It works fine with .doc files and fails only in case of XL files.
With XL do you really mean Microsoft Excel (*.xls)? If so, Excel (and Word (*.doc)) files are binary, and cannot be read properly using Readers. You need to use InputStreams for them, and then parse them properly. Check out Accessing File Formats. For Excel you can use either Apache POI or JExcelAPI.
Joined: Aug 07, 2009
Thanks a lot Rob!! That did seem to solve my problem.
My new code - which works well :-) is as follows -
Again, Thanks a Lottttt Rob!! Your guidance really helped me getting this right!
Jyotsna Pai wrote:Thanks a lot Rob for your prompt reply. It really helped me a lot!!! And made me realize that file can only work with local files.
Actually, that's not true. But a file server is not a web server. When using the http protocol, you are placing a request for a web server to retrieve or construct a resource and return it as a sequential data stream with HTTP headers as needed. Whether it actually locates a file on the server's filesystem or synthesizes data from scratch is totally dependent on how the web application was written. File servers just locate files and allow remote read/write/directory access in accordance with the requesters access rights. Despite the resemblance between filesystem pathnames and URLs, the two types of string are not the same thing.
Joined: Aug 07, 2009
Firstly, Thanks for your reply in helping us resolve the issue!!
But just quickly though, we were discussing about a java.io.file constructor being able to access remote files whether a web/file server.
What I was wondering about was why the File constructor was not able to take a http protocol as "http://" and was taking only "http:/" no matter how I tried to specify the string in the File constructor to begin with http://. Rob made me understand that java.io.file can work only with local files and not remote files.
When I was trying to retrieve a remote file on the development/web server (on UNIX platform) which hosts this web application.
I never faced any issue with a .doc file. I only faced problem with MS - .xls files.
After Rob's suggestion to use InputStream class since the files were binary, it helped me resolved my problem. (Details in my previous message.)
Please advise whether java.io.file constructor can work only with local files or can it work with remote files as well. Also, if the java.io.File constructor can retrieve/create a "remote" file, how to specify the StringURL to accept the http protocol using the constructor - File file = new File("StringURL");
"http:" is the name of a protocol. You can't use protocols with java.io.File. To specify resource location using a protocol, you use java.net.URL and you use a java.net Connection object to access the data for that URL. There are a number of standard protocols and others can be plugged in as well. For example, "ftp:" indicates use of the FTP protocol. For files, the protocol name is "file:". Thus, you can access file data by constructing an input stream on a java.iot.File object or by constructing an input stream on a Connection object for a File-protocol URL such as "file:///c|/Program Files/Tomcat/conf/server.xml". If you supply a protocol as the input String to the File constructor, it will think that you're specifiying the protocol as part of the file name and not do what you expect. For example, there's no such thing as an "lpt1:" protocol, so opening a URL connection for "lpt1:" would fail, but opening a File would create access to the DOS printer device.
The "file:" protocol is a convenience feature. It allows URLs to reference filesystem objects in the same way as web servers, ftp servers, ldap servers and a great many other things. However, in exchange for this flexibility, URL references are more complex to code and you can't do basic filesystem operations on them the way you can when using java.io.File. You never specify a protocol for java.io.File. You should always specify a protocol for a URL unless you're building it relative to another URL.
Notice that not once did I ever say "local file" or "remote file". To access remote files, you must access a remote file server. If the file/directory you want isn't presented by a remote file server then you can't access the file. To make it work any other way would allow me - or anyone else - to plunder and pillage any computer on Earth.
Remote file references can be made "floating" using network names. For Windows networking, that's a UNC name in the form \\hostname\sharename. For Unix NFS it's "hostname:/sharename/path".
Network names don't work everywhere, though. So for best accessibility you should mount the network name to a local mountpoint. In Unix, the "mount" command does that. In Windows, the "NET USE" command assigns a drive letter to a UNC name. Once mounted, for the most part, the OS can't tell whether the file is local or remote. Most of the differences have to do with directory attributes, since Windows and Unix are quite a bit different in that regard.