The same issue was found on WAS 7.0.0.0.

QA reproduced with the fileEntry regression app using WebSphere 8.5.0.2, so it's specific to the app container, and not the composite-showcase.

http://localhost:8080/fileEntry/fileEntryFileNameEncoding.jsf

There are two problems, the first being the file name not being correct, and the second is that no response is coming back when using trunk ICEfaces 3 (just after EE 3.3 release) wit the fileEntry QA test app, due to getting an exception when trying to report an exception. Here is the original exception:

[7/8/13 20:36:18:888 EDT] 00000093 SystemErr R javax.faces.FacesException: java.lang.StringIndexOutOfBoundsException
[7/8/13 20:36:18:889 EDT] 00000093 SystemErr R at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:257)
[7/8/13 20:36:18:889 EDT] 00000093 SystemErr R at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
[7/8/13 20:36:18:889 EDT] 00000093 SystemErr R at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
[7/8/13 20:36:18:889 EDT] 00000093 SystemErr R at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
[7/8/13 20:36:18:889 EDT] 00000093 SystemErr R at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
[7/8/13 20:36:18:889 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1225)
[7/8/13 20:36:18:890 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:775)
[7/8/13 20:36:18:890 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:457)
[7/8/13 20:36:18:890 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
[7/8/13 20:36:18:890 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1032)
[7/8/13 20:36:18:890 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:87)
[7/8/13 20:36:18:890 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:908)
[7/8/13 20:36:18:891 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662)
[7/8/13 20:36:18:891 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:195)
[7/8/13 20:36:18:891 EDT] 00000093 SystemErr R at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:459)
[7/8/13 20:36:18:891 EDT] 00000093 SystemErr R at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:526)
[7/8/13 20:36:18:891 EDT] 00000093 SystemErr R at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:312)
[7/8/13 20:36:18:891 EDT] 00000093 SystemErr R at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:87)
[7/8/13 20:36:18:892 EDT] 00000093 SystemErr R at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
[7/8/13 20:36:18:892 EDT] 00000093 SystemErr R at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
[7/8/13 20:36:18:892 EDT] 00000093 SystemErr R at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
[7/8/13 20:36:18:892 EDT] 00000093 SystemErr R at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
[7/8/13 20:36:18:892 EDT] 00000093 SystemErr R at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
[7/8/13 20:36:18:892 EDT] 00000093 SystemErr R at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
[7/8/13 20:36:18:893 EDT] 00000093 SystemErr R at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
[7/8/13 20:36:18:893 EDT] 00000093 SystemErr R at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1815)
[7/8/13 20:36:18:893 EDT] 00000093 SystemErr R Caused by: java.lang.StringIndexOutOfBoundsException
[7/8/13 20:36:18:893 EDT] 00000093 SystemErr R at java.lang.String.substring(String.java:1148)
[7/8/13 20:36:18:894 EDT] 00000093 SystemErr R at com.sun.faces.renderkit.ServerSideStateHelper.getState(ServerSideStateHelper.java:283)
[7/8/13 20:36:18:894 EDT] 00000093 SystemErr R at com.sun.faces.renderkit.ResponseStateManagerImpl.getState(ResponseStateManagerImpl.java:100)
[7/8/13 20:36:18:894 EDT] 00000093 SystemErr R at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:526)
[7/8/13 20:36:18:894 EDT] 00000093 SystemErr R at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:141)
[7/8/13 20:36:18:894 EDT] 00000093 SystemErr R at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:192)
[7/8/13 20:36:18:895 EDT] 00000093 SystemErr R ... 25 more
[7/8/13 20:36:52:399 EDT] 00000093 SystemErr R javax.faces.FacesException: java.lang.StringIndexOutOfBoundsException
[7/8/13 20:36:52:400 EDT] 00000093 SystemErr R at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:257)
[7/8/13 20:36:52:400 EDT] 00000093 SystemErr R at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
[7/8/13 20:36:52:401 EDT] 00000093 SystemErr R at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
[7/8/13 20:36:52:401 EDT] 00000093 SystemErr R at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
[7/8/13 20:36:52:401 EDT] 00000093 SystemErr R at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
[7/8/13 20:36:52:401 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1225)
[7/8/13 20:36:52:402 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:775)
[7/8/13 20:36:52:402 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:457)
[7/8/13 20:36:52:402 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
[7/8/13 20:36:52:402 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1032)
[7/8/13 20:36:52:402 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:87)
[7/8/13 20:36:52:402 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:908)
[7/8/13 20:36:52:402 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662)
[7/8/13 20:36:52:403 EDT] 00000093 SystemErr R at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:195)
[7/8/13 20:36:52:403 EDT] 00000093 SystemErr R at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:459)
[7/8/13 20:36:52:403 EDT] 00000093 SystemErr R at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:526)
[7/8/13 20:36:52:403 EDT] 00000093 SystemErr R at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:312)
[7/8/13 20:36:52:403 EDT] 00000093 SystemErr R at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:283)
[7/8/13 20:36:52:403 EDT] 00000093 SystemErr R at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
[7/8/13 20:36:52:403 EDT] 00000093 SystemErr R at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
[7/8/13 20:36:52:404 EDT] 00000093 SystemErr R at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
[7/8/13 20:36:52:404 EDT] 00000093 SystemErr R at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
[7/8/13 20:36:52:404 EDT] 00000093 SystemErr R at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
[7/8/13 20:36:52:404 EDT] 00000093 SystemErr R at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
[7/8/13 20:36:52:404 EDT] 00000093 SystemErr R at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
[7/8/13 20:36:52:404 EDT] 00000093 SystemErr R at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
[7/8/13 20:36:52:405 EDT] 00000093 SystemErr R at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
[7/8/13 20:36:52:405 EDT] 00000093 SystemErr R at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1815)
[7/8/13 20:36:52:405 EDT] 00000093 SystemErr R Caused by: java.lang.StringIndexOutOfBoundsException
[7/8/13 20:36:52:405 EDT] 00000093 SystemErr R at java.lang.String.substring(String.java:1148)
[7/8/13 20:36:52:406 EDT] 00000093 SystemErr R at com.sun.faces.renderkit.ServerSideStateHelper.getState(ServerSideStateHelper.java:283)
[7/8/13 20:36:52:406 EDT] 00000093 SystemErr R at com.sun.faces.renderkit.ResponseStateManagerImpl.getState(ResponseStateManagerImpl.java:100)

That StringIndexOutOfBoundsException was actually just an error introduced in my workplan from adding all the encoding debug. It's fixed.

There were basically two parts of the code that needed to be altered to address this issue. The first was that in WebSphere 8.5 the request and external encodings are null, so we needed to parse it out from the header ourselves. Luckily, there was already code doing that in ICEfaces, we just needed the fileEntry multipart parsing to make use of it. Secondly, we had only been passing in our idea of the encoding into the form field parsing, and we also needed to use the apache commons upload api for setting the encoding used to parse where the file name information is.

icefaces3 trunk
Subversion 36610

Needs to be tested again in the original ee-composite-showcase scenario to verify fix.

In testing, QA found that the test app was showing the uploaded file name correctly in the updated web page, but the file in the file system was still not correct.

We ascertained that putty was not showing extended characters properly, but that WinSCP can. Also, the WAR extraction included the files with accents, and those did not have the correct file names, so that has an issue on that system as well.

I've augmented the QA Sparkle Nightly fileEntry app, so that the fileEntryFileNameEncoding page will show the actual file-system path.
Subversion 34906

Oddly, the test app shows the accents in the File's path, while the file continues to not show the accents in WinSCP, even though if you directly upload the file using WinSCP, it shows the accents then, in both the local and remote view.

Added display of the uploaded File's path, absolute path, canonical path (more system dependent), as well as the parent folder's children's canonical paths.
Subversion 34907

The page output is now showing the path and absolute path as having the accents and the canonical paths as being questions marks, like we see in WinSCP. Coupled with the fact that WAR deployment writes out the files with questions marks instead of accents, points to a Linux admin or WebSphere admin issue with character encodings. So we'll test with Tomcat 7 on an Amazon instance and see if that has the problem as well.

Tomcat 7 on this Linux Amazon instance does in fact have the same problem. Turns out that while OS X internally encodes files in UTF-16 and includes all the character encoding conversion to make that work, Linux doesn't care nor involve itself in filename character encoding, and thus every application needs to do it properly. There are environment variables that guide libc using applications in accomplishing this, but the JVM may need to be configured differently, since it doesn't seem to respond to those environment variables being set on the commandline before executing the Tomcat process.

Linux file system character encoding info:
http://benjamin-schweizer.de/unix-terminals-surviving-the-encoding-hell.html
http://unix.stackexchange.com/questions/15419/several-questions-about-file-system-character-encoding-on-linux
http://hektor.umcs.lublin.pl/~mikosmul/computing/articles/linux-unicode.html
http://documentation.basis.com/BASISHelp/WebHelp/inst/character_encoding.htm

LANG, LC_ALL env vars

Java:
http://stackoverflow.com/questions/10106161/encoding-of-file-names-in-java

java -Dfile.encoding=UTF8

QA fileEntry app report the file.encoding system property and Charset default encoding.
Subversion 34912

When using Terminal from my OS X 10.7.5 Mac, Tomcat on Linux works, it appears to automatically derive LANG from my client machine (LANG=en_CA.UTF-8). The JVM debug shows it's using UTF-8, and both the unWARed files and the uploaded files look correct.

Confirmed WebSphere 8.5.0 works as well, when launching everything from the Terminal from my OS X 10.7.5 Mac. Confirmed that a Windows browser and Mac Firefox browser could upload the files, and the canonical paths looked good in the browsers, as well as a terminal inspection of the upload folders on the Linux server.

So, with the component fix, proper server environment configuration (automatic from Terminal.app), and appropriate ssh client that works with UTF-8, it works.

Ported to ICEfaces EE 3.3.0 GA P01
Subversion 36680