Richfaces 4.0 fileupload

[albitkin]

I need to upload file and pass it to another module for processing.

In Richfaces.3.3.3 I was able to get upladed file's name and path:

UploadedItem item=event.getUploadedItem

serverFileName=item.getFile.getPath();

In Richfaces 4.0

UploadeFile item=event.getUploadeFile()

item doesn't give me access to Server file name.

What should be correct way to fix it?

[nbelaevski]

Hi Albert,

The simplest thing you can do is moving file to another location via http://download.oracle.com/javase/1.4.2/docs/api/java/io/File.html#renameTo(java.io.File)

[albitkin]

Hi, Nick

Thank you for the answer, but the problem is I don't think there is access to File object of UpdateFile class. File object is there, I can see it during debugging, but it's private and there is no public method getFile(), as it was in RichFaces 3.3

[fabmars]

I have the same remark as you.

The point for me is to directly move the temp file to its final place and give it the name I want. That way the temp file needn't be copied hence not taking twice its size on the disk.

UploadedFile has 2 implementations: BaseUploadedFile (abstract) and UploadedFile25. None of them offers access to the File object.

But they contain (without exposing it) some FileUploadResource object which is the one really pointing at the uploaded content. This interface has 2 implementations (FileUploadDiscResource/FileUploadMemoryResource) which are created (depending on the web.xml config) in a good old MultipartRequestParser! No surprise under the hood. Now let's look at FileUploadDiscResource which contains what we're looking for: the temp files created are marked deleteOnExit().

After looking at the code, to me it's clear we will never be allowed to retrieve the File from the UploadedFile. Of course we can't go back to the FileInputStream's file through getInputStream(). So we have no choice: duplicate the files on the disk and call UploadedFile.delete at the end.

If the files are very big, we'll have to tweak a little more and use an asynch processing not to block the UI. Well, too bad indeed there's this feeling of having less flexibility than in RF 3.x, but I'll survive.