deployment on localized windows has problem

[glassfishrobot]

See http://www.netbeans.org/issues/show_bug.cgi?id=70391.

The cause appears to be the deployment code on the 'server side'.

This has also been reported in various forums.

Environment

Operating System: All Platform: All

Affected Versions

[9.0pe]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/601
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @yaminikb
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented @honghzzhang said: Assign to tim to take a look.

[glassfishrobot]

@glassfishrobot Commented @tjquinno said: The current implementation uses getAbsolutePath() on a File object for the archive file. When the path includes a multi-byte character, the resulting string for the absolute path includes \uxxx for the special character. But when this is used in File f = new File(path) a subsequent f.exists() returns false.

I'm looking into the best way to resolve this.

• Tim

[glassfishrobot]

@glassfishrobot Commented @tjquinno said: I was able to reproduce this problem by creating a directory containing a multi-byte character and specifying my Windows TEMP environment variable to point to that directory.

It took a little while, but I have traced this problem to the admin upload mechanism. I think that both the UploadServlet (on the server side) and the FileUploadUtil (on the client side) may need to be changed.

The FileUploadUtil.uploadToServlet reads the response from the upload servlet specifying the char. encoding UTF8. I think this should be UTF-8.

Also, I think the UploadServlet.writeResponse method needs to specify the character encoding on the response to UTF-8 before getting the writer. It may also need to prepare the string that is written to the response writer using UTF-8 as the encoding. I tried some experiments in my local workspace changing both of those and was able to get the scenario to work. It is possible that changing only the writer's encoding would be sufficient but I did not try that.

I am reassigning this issue to the admin team which owns the two relevant classes.

[glassfishrobot]

@glassfishrobot Commented @tjquinno said: Adding Hong to the interest list.

[glassfishrobot]

@glassfishrobot Commented @tjquinno said: I'm reclaiming ownership of this because the classes affected were added as part of SeeBeyond integrations of deployment changes.

[glassfishrobot]

@glassfishrobot Commented @tjquinno said: Reclaimed ownership.

[glassfishrobot]

@glassfishrobot Commented @tjquinno said: Revised target to 9.0PE UR1.

[glassfishrobot]

@glassfishrobot Commented @tjquinno said: The fix has been checked in to the main trunk (9.1). The backport for 9.0ur1 is underway.

[glassfishrobot]

@glassfishrobot Commented @tjquinno said: Was fixed in the main trunk earlier. Now also checked in to the 9.0PEur1 code base as well.

[glassfishrobot]

@glassfishrobot Commented @amyroh said: update target milestone to reflect build number.

[glassfishrobot]

@glassfishrobot Commented Was assigned to tjquinno

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-601

[glassfishrobot]

@glassfishrobot Commented Reported by @vkraemer

[glassfishrobot]

@glassfishrobot Commented Marked as fixed on Thursday, May 17th 2007, 4:08:27 am