I have recently playing around with JSF and Tomahawk tags and API. One feature I used from Tomahawk was the file upload tag <t:inputFileUpload>. I got everything working but I just don't understand why the UploadedFile created by Tomahawk is not a physical file once it said it's uploaded. I'm using JBoss app server and when I upload, it says the file is at the bin folder. Yet when I look inside the bin folder, the file isn't there.
Why is this? Does Tomahawk store the file data all in memory (like when uFile.getInputStream() to read file)?
I asked this because I hope to use the Commons IO FileUtils.copyFile() to copy this uploaded file for later processing (like in a batch process), but since the file doesn't exist, the copy can't be done. Also I really don't want to read the file and write again for large files.
I don't know anything about Tomahawk! But I do file uploading successfully this way
1. I create physical file :
file = new File(uploadPath + "\\" + email+""+JavaHelpConstants.USER_PHOTO_EXTENSION.toString());
//new file is created to store uploaded photo
2. Write uploaded photo into existent file:
// uploaded photo(org.apache.commons.fileupload.FileItem) is written into new file
This way file is really uploaded. Maybe UploadedFile provides the ability to write content into physical file.
I understand your approach works using Commons IO API. However, it requires a HTTPServletRequest which when detected looks for form/multi-part type. Yet in my JSF bean, once got the request, it's not form/multi-part. So can't get or cast to FileItem.
Hi I am trying to use the tomahawk upload, i am getting below error
[3/25/13 17:33:57:004 EDT] 00000017 LRUMapCacheFa I org.ajax4jsf.cache.LRUMapCacheFactory createCache Creating LRUMap cache instance of default capacity
[3/25/13 17:33:57:082 EDT] 00000017 renderkit E Not in GZIP format
java.io.IOException: Not in GZIP format
This isn't just a Tomahawk thing. The J2EE file upload process never writes the uploaded data to a file. A web server is not a file server.
When you "upload a file", what you are actually doing is submitting an HTTP MIME-encoded multi-part form. The client (browser) doesn't actually do a file operation against the server. Instead, it opens the indicated client file, reads what's in the file, converts it to MIME encoding (since HTTP cannot handle pure binary data), wraps some markers around the encoded data, and then includes the encoded data as part of the uploaded form data.
When the J2EE server receives this form, the uploaded file(s) is/are extracted from the incoming data stream and cached. The server application can then do whatever it wants with that data, including copying it into a server-side file, storing the file data as a BLOB or CLOB in a database, updating existing data or simply dissecting the data and using it directly for application control and discarding it.
The "file name" is a bit of a deception. What this value actually is is the value associated with the file data that was uploaded. In most cases, that name is related to where on the client's filesystem the data came from (its file name), but it could be whatever the client software wanted to jam in there.
Just to further confuse things, Internet Explorer has a habit of making the file name be the client-side filesystem path, not just the filename itself. This is actually a security exposure, but that's IE for you. It's also why you think that your uploaded file is in a directory somewhere - you're seeing the client path.
In order to actually take the uploaded file data and store it in a server-side file, you have to use the file upload API to obtain the file data as an input stream and copy it to an actual file that your application code creates. What you name that file and where you place it is up to you, except that your should NOT store the uploaded data within your application WAR directory tree or in any of the directories that hold your webapp server. If you do either of these things, chances are good that sooner or later, you will regret it.
An IDE is no substitute for an Intelligent Developer.