• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Tomahawk file upload and JSF

 
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 514
1
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello!

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
file.createNewFile();
2. Write uploaded photo into existent file:
// uploaded photo(org.apache.commons.fileupload.FileItem) is written into new file
fileItem.write(file);
This way file is really uploaded. Maybe UploadedFile provides the ability to write content into physical file.
 
K. Tsang
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)

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

web.xml
<filter>
<filter-name>Extensions Filter</filter-name>
<filter-class>org.apache.myfaces.webapp.filter.ExtensionsFilter</filter-class>
<init-param>
<description>
Set the size limit for uploaded files.
Format: 10 - 10 bytes
10k - 10 KB
10m - 10 MB
1g - 1 GB
</description>
<param-name>uploadMaxFileSize</param-name>
<param-value>1g</param-value>
</init-param>
<init-param>
<description>
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
</description>
<param-name>uploadThresholdSize</param-name>
<param-value>100k</param-value>
</init-param>
<init-param>
<description>
Set the path where the intermediary files will be stored.
</description>
<param-name>uploadRepositoryPath</param-name>
<param-value>/temp</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>Extensions Filter</filter-name>
<servlet-name>Faces Servlet</servlet-name>
</filter-mapping>

Any idea why i am getting above exception??
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic