3 Replies Latest reply on Sep 5, 2011 8:31 PM by Fab Mars

    Richfaces 4.0 fileupload

    Albert Itkin Newbie

      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



      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?

        • 2. Re: Richfaces 4.0 fileupload
          Albert Itkin Newbie

          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

          • 3. Re: Richfaces 4.0 fileupload
            Fab Mars Novice

            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.