ICEfaces
  1. ICEfaces
  2. ICE-9883

showcase - ace:fileEntry upload mangles unicode filenames on JBoss/WildFly 8.0

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 4.0.BETA
    • Fix Version/s: None
    • Component/s: ACE-Components, Sample Apps
    • Labels:
      None
    • Environment:
      ICEfaces4 trunk rev# 40075/ 40089
      App server: wildfly-8.0.0.Final (JBoss 8.0) @ Windows7
      Browsers: Firefox27
      Testing used the app server stock JSF.
    • Workaround Exists:
      Yes
    • Workaround Description:
      It would likely be possible to write a filter that would find filenames in the upload and decode the bytes, as an application-level workaround.

      Description

      showcase -> FileEntry
      > Overview: on this showcase demo - files don't appear to be uploaded on the server, although the message rendered on page confirms successful uploads.
      On tomcat7, the files are uploaded from this demo in a directory /files/[session name], like this:
      C:\Servers\apache-tomcat-7.0.27\temp\0-showcase\files\48CB4A19796D98841EC534E5EA917139.

      > Overview/Validation/Callback: when uploading files with names containing special unicode characters, the confirmation message fails to render properly the file name on page, as example when uploading äöü€.txt, the characters are rendered as in attached screen shot; this is also an issue if using the QA fileEntry test application (http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/fileEntry) on WildFly/JBoss8.0.



      Deryk:
       I was able to see the files uploaded - just to an odd location. On my Mac they were located at ./wildfly-8.0.0.Final/bin/null/1DE2666E626C639233B821E2B7B160CA. Confirming Carmen’s observation about the characters. The files are saved in the same location as noted above and the characters have already been ‘changed' so the conversion occurs before or during saving of the files and the rendered display is simply reflecting this.

        Activity

        Carmen Cristurean created issue -
        Carmen Cristurean made changes -
        Field Original Value New Value
        Attachment fileEntry-wildFly8.PNG [ 16702 ]
        Carmen Cristurean made changes -
        Description showcase -> FileEntry
        > Overview: on this showcase demo - files don't appear to be uploaded on the server, although the message rendered on page confirms successful uploads.
        On tomcat7, the files are uploaded from this demo in a directory /files/[session name], like this:
        C:\Servers\apache-tomcat-7.0.27\temp\0-showcase\files\48CB4A19796D98841EC534E5EA917139.

        > Overview/Validation/Callback: when uploading files with names containing special unicode characters, the confirmation message fails to render properly the file name on page, as example when uploading äöü€.txt, the characters are rendered as in attached screen shot; this is also an issue if using the QA fileEntry test application on WildFly/JBoss8.0.



        Deryk:
         I was able to see the files uploaded - just to an odd location. On my Mac they were located at ./wildfly-8.0.0.Final/bin/null/1DE2666E626C639233B821E2B7B160CA. Confirming Carmen’s observation about the characters. The files are saved in the same location as noted above and the characters have already been ‘changed' so the conversion occurs before or during saving of the files and the rendered display is simply reflecting this.
        showcase -> FileEntry
        > Overview: on this showcase demo - files don't appear to be uploaded on the server, although the message rendered on page confirms successful uploads.
        On tomcat7, the files are uploaded from this demo in a directory /files/[session name], like this:
        C:\Servers\apache-tomcat-7.0.27\temp\0-showcase\files\48CB4A19796D98841EC534E5EA917139.

        > Overview/Validation/Callback: when uploading files with names containing special unicode characters, the confirmation message fails to render properly the file name on page, as example when uploading äöü€.txt, the characters are rendered as in attached screen shot; this is also an issue if using the QA fileEntry test application (http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/fileEntry) on WildFly/JBoss8.0.



        Deryk:
         I was able to see the files uploaded - just to an odd location. On my Mac they were located at ./wildfly-8.0.0.Final/bin/null/1DE2666E626C639233B821E2B7B160CA. Confirming Carmen’s observation about the characters. The files are saved in the same location as noted above and the characters have already been ‘changed' so the conversion occurs before or during saving of the files and the rendered display is simply reflecting this.
        Carmen Cristurean made changes -
        Assignee Deryk Sinotte [ deryk.sinotte ]
        Ken Fyten made changes -
        Affects Version/s 4.0.BETA [ 10770 ]
        Ken Fyten made changes -
        Assignee Deryk Sinotte [ deryk.sinotte ] Ted Goddard [ ted.goddard ]
        Assignee Priority P2 [ 10011 ]
        Ken Fyten made changes -
        Summary showcase - fileEntry upload issues (JBoss/WildFly 8.0 specific) showcase - ace:fileEntry upload mangles unicode filenames on JBoss/WildFly 8.0
        Ken Fyten made changes -
        Security Private [ 10001 ]
        Ken Fyten made changes -
        Fix Version/s EE-4.0.0.GA [ 11171 ]
        Fix Version/s 4.0.BETA [ 10770 ]
        Ken Fyten made changes -
        Fix Version/s EE-4.0.0.GA [ 11171 ]
        Ken Fyten made changes -
        Workaround Description It would likely be possible to write a filter that would find filenames in the upload and decode the bytes, as an application-level workaround.
        Workaround Exists Yes [ 10007 ]
        Assignee Priority P2 [ 10011 ]
        Ken Fyten made changes -
        Status Open [ 1 ] Closed [ 6 ]
        Resolution Won't Fix [ 2 ]

          People

          • Assignee:
            Ted Goddard
            Reporter:
            Carmen Cristurean
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: