You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Joe Germuska <jo...@germuska.com> on 2006/03/01 18:11:50 UTC
Re: FormFile throws Serializable exception in session scope
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: FormFile throws Serializable exception in session scope
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
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" <jo...@germuska.com>
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org