wood burning stoves 2.0
The moose likes JSF and the fly likes Tomahawk file upload and JSF Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "Tomahawk file upload and JSF " Watch "Tomahawk file upload and JSF " New topic

Tomahawk file upload and JSF

K. Tsang

Joined: Sep 13, 2007
Posts: 3132

Hello ranchers

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.

Thanks in advance.

K. Tsang JavaRanch SCJP5 SCJD OCPJP7 OCPWCD5 OCPBCD5 OCPWSD5 OCMJEA5 part 1 part 2/3
Volodymyr Lysenko
Ranch Hand

Joined: Mar 29, 2012
Posts: 511


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.

True person is moral, false is right!
K. Tsang

Joined: Sep 13, 2007
Posts: 3132

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.
Learner Comp

Joined: Mar 25, 2013
Posts: 1
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
at java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:148)
at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:69)
at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:79)

<t:inputFileUpload id="inputFileUpload" value="#{pc_testUpload.uploadedFile}" size="35" required="true" requiredMessage="Document is required." storage="file" styleClass="btn">

<filter-name>Extensions Filter</filter-name>
Set the size limit for uploaded files.
Format: 10 - 10 bytes
10k - 10 KB
10m - 10 MB
1g - 1 GB
Set the threshold size - files below this limit are stored
in memory, files above this limit are stored on disk.
Format: 10 - 10 bytes
10k - 10 KB
10m - 10 MB
1g - 1 GB
Set the path where the intermediary files will be stored.
<filter-name>Extensions Filter</filter-name>
<servlet-name>Faces Servlet</servlet-name>

Any idea why i am getting above exception??
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17421

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.
I agree. Here's the link: http://aspose.com/file-tools
subject: Tomahawk file upload and JSF
It's not a secret anymore!