I've put the code in pretty much as posted by the forum user with the addition of a context-parameter that forces the code to use the safe (but slow) practice of executing the lifecycle on the calling thread.

The context parameter name is com.icesoft.faces.forceLifecycleOnCallingThread and the default value is false.

+1 for this solution

The UploadServer detects typical situations where we know there are ThreadLocal fields, like with Seam and Spring, and uses the current thread to do the lifecycle, otherwise it will default to using a different thread to do the lifecycle, leaving the current thread to continue processing uploaded data. This is to avoid losing performance unnecessarily. This specific problem is that we're not using the current thread in a Spring Security environment (I guess they're not using anything else from Spring), which also uses some ThreadLocal field(s). The generic problem is that we'll never be able to anticipate third party library uses of ThreadLocal fields.

From talking with Deryk, it looks like the most straightforward solution is to add two more criteria to the decision to use the current thread for the lifecycle. The first being a check for Spring Security, and the second being a flag to force using the conservative threading model. That way, developers can just set a context-param, and not have to change or recompile ICEfaces, when integrating with any other libraries. At least as it pertains to uploading files.