The DeferredFileOutputStream used in Commons FileUpload 1.1 is the one from Commons IO (in FileUpload 1.0 it was a commons FileUpload class) - so if you're still seeing the same exception referencing "org.apache.commons.fileupload.DeferredFileOutputStream" then that would indicate you're still using FileUpload 1.0.
The DeferredFileOutputStream from Commons IO ("org.apache.commons.io.output.DeferredFileOutputStream") is still not Serializeble - but the instance variable in DiskFileItem has been made transient. A serialization test was added as part of the fix for the bug you reference (see http://tinyurl.com/kx77e ) - there could be a problem with that test, but my first inclination would be that the issue is something in your deployment. Niall ----- Original Message ----- From: "Joe Germuska" <[EMAIL PROTECTED]> Sent: Wednesday, March 01, 2006 5:11 PM > Ben <newreaders <at> gmail.com> writes: > > > > > I defined an ActionForm of which it has a FormFile. Prepopulation is > > not needed for this ActionForm. Configuring this ActionForm is similar > > to any other forms and here is the exception. I get this exception > > when I startup/shutdown Tomcat. > > ... > > > 2005-11-11 09:45:30,000 WARN > > [ContainerBase.[Catalina].[localhost].[/]] - Cannot serialize session > > attribute uploadForm for session 0556C80B681118276F9F2B02FEC497E0 > > java.io.NotSerializableException: > > org.apache.commons.fileupload.DeferredFileOutputStream > > DeferredFileOutputStream is not serializable in commons-fileupload before > version 1.1. > > (see http://issues.apache.org/bugzilla/show_bug.cgi?id=32785, > http://jakarta.apache.org/commons/fileupload/changelog-report.html) > > However, having just run into this problem myself, the solution is not as simple > as merely changing the commons-fileupload dependency. I'm just starting to > scout this out myself, but I'm wondering if Struts needed to have some update to > use the correct classes, or if I'm just blundering and I missed something else > more straightforward. > > In any case, it appears that CommonsMultipartRequestHandler has not actually > been updated to catch up with deprecations in commons-fileupload 1.1, but I > haven't yet figured out if that is the reason simply using the newer > commons-fileupload is still resulting in a problem with the serialization. > > http://struts.apache.org/struts-action/xref/org/apache/struts/upload/CommonsMultipartRequestHandler.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]