Announcement Announcement Module
Collapse
No announcement yet.
CommonsMultipartResolver and corrupt files Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • CommonsMultipartResolver and corrupt files

    I've been trying to implement upload functionality with CommonsMultipartResolver.

    Since I needed the original filename, I haven't used the ByteArrayMultiPartEditor but I've used a bean with a MultipartFile field. When the upload is finish I save the file to disk.

    Everything seems to work, no Exceptions are thrown. But binary files end up being corrupt. When I look at a file it seems to be about right (I can see the jpeg headers for example). This behaviour occurs on a Windows XP and a Debian machine.

    Does anybody have any clues about what's going wrong?

  • #2
    imagedb sample, from Spring distribution, shows how to use CommonsMultipartResolver to upload binary files.
    HTH

    Comment


    • #3
      I've been experimenting, but I haven't had much luck. It seems to me that the approach I'm using should work.

      I've got a command class with a MultiPartFile field, there's a CommonsMultiPartResolver active. A SimpleFormController sets the fields of the command class.

      When I save the contents of the MultiPartFile to disk through either saving the byte array, or using the InputStream binary data gets corrupt.

      The imagedb example seems to use an approach very similar to mine, but it saves to jdbc.

      What could be wrong in my approach?

      Comment


      • #4
        Now I've tried the exact same approach used in Appfuse and the imagedb demo. A command class with a byte[] field and getting the CommonsMultiPartRequest to save the file.

        Still the same symptoms, jpegs have a few glitches and gifs are nearly completely corrupt.

        I don't really get the idea behind this approach. To me it seems to go directly against the spring design principles, You have to get a commons specific object from the request instead of defining the field in the most generic way in the command class.

        I'm running out of options here, is this a problem a lot of people run into?

        Comment


        • #5
          I have no problems with corruption using this technique
          Code:
          MultipartHttpServletRequest multipartRequest = (MultipartHttpServletRequest) request; 
          Map multiPathFiles = multipartRequest.getFileMap();
          if (multiPathFiles != null) {
          			for (Iterator it = multiPathFiles.keySet().iterator(); it.hasNext();) {
          				String keyName = (String) it.next();
          				MultipartFile file = (MultipartFile) multiPathFiles.get(keyName);
          				if (file != null && file.getBytes().length > 0) {
          					manageDao.insertUpdateInputStream(file.getInputStream(), file.getOriginalFilename(), collectionPath);
          				}
          			}
          		}
          maybe its your "to-disk" saving code. can you post it??

          Comment


          • #6
            I use the same approach as Stuart only I store the uploaded file(s) to disk using the transferTo method of MultipartFile. It has been working very nicely.

            Comment


            • #7
              I'm beginning to think the problem's not my disk saving code, but that the problem occurs before my code kicks in.

              I've tried three different approaches, including the Commons transferTo method.

              Could this be an encoding related issue? My jvm and webapp are running in ISO-8859-1.

              Comment


              • #8
                I've been trying and trying every method of using the MultiPartResolver I've seen on the web the last week, but still no success. I'm 99% sure the files get corrupt before they reach my code.

                Has anybody anywhere got any clue or tip for me?

                Comment


                • #9
                  I'm still strugling with this problem. I now found out it works fine if the server runs on Mac Os X, but the files keep getting corrupt on Debian Linux or Windows.

                  Has anybody got any suggestion? I'm getting near to giving up and start using .Net or something :-).

                  Comment


                  • #10
                    I'm getting quite desperate.

                    I've tried everything there is to try, different encodings for the client, webserver and jvm.

                    I know my own filesaving code isn't the problem. I've saved files with the class and compared the md5 hashes, they're the same. So the problem must occur in commons fileupload or the CommonsMultipartResolver.

                    Could anybody give me any hint or option to look into? The release date of the app is getting close and this problem that I haven't been able to solve for 2 months is starting to look like the only showstopper for the release.

                    Comment


                    • #11
                      Finally i've found a solution.

                      It turns out there's a nasty bug in Resin 3.0.8 that corrupts binary uploads. I've patched the server and now it's working fine.

                      It would have been nice if Caucho would have put some information up on this matter, it's almost impossible to find it through google...

                      Comment

                      Working...
                      X