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]

Reply via email to