- Tried commons-upload newest version 11604 nightly, not compatible with
Struts 1.2.4. This is a commons-upload 1.1 development build that seems to
be completely refactored. Nice, there seem to be portlet features support
coming up. However, there is no specification version mentioned in the
manifest so I could tell what the latest struts-1.2.4-compatible version
would be.
=> So,
- Modified commons-upload source package 1.0, making the
DeferredOutputStream serializable with empty write/readObject:s - seems to
circumvent the problem. Can somebody foretell any nasty side-effects of
doing such a kludge ? Restoring the user's session on failover will still
have unpredictable results, if in the middle of file upload, but at least
the rest of the user's session will now be restored.
=> session size now expectedly grows, but not proportionately to uploaded
file size. Apparently caching of the blob itself now got prevented, good...
Is there any way _not_ to put the Form into the HttpSession in the first
place, Struts guys ? I'm now explicitly removing it after the use case
has completed...
Grateful for any better solutions, obvious or not -
//markku
PS. This was intended to be an innocent-black-box-user -type of a thread,
but I see it might be a bit OT for the user list, pardon that... Should I
post this to dev list as well, dunno.
[EMAIL PROTECTED] wrote on 16.11.2004 17:46:04:
Hello -
I'm using Struts 1.2.4 HTML form upload to upload files (e.g. FormFile
and
commons-upload 1.0 bundled with Struts )
In order to keep my app clusterable, I want to keep all HttpSession
content
serializable.
To enforce this in a non-app-server-specific way (and also to get
heuristics on session size)
I have a layer in my app framework that attempts to serialize all session
content to a ByteArrayOutputStream at development time.
There is something that looks like a serialization problem with the
commons
internals -
java.io.NotSerializableException:
org.apache.commons.fileupload.DeferredFileOutputStream
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
I recall seeing an attempt somewhere (in release notes of an earlier
Struts
version ?) toward a similar problem, possibly in an upper layer of
commons.fileupload, couldn't find it anymore though.
Q1: Any workaround for this (newer commons-upload.jar ?) , or am I trying
to serialize something that will somehow automagically be cleaned up
before
e.g. cluster session failover ??
Q2: Doesn't silent caching of the form incur a risk of serializing very
large blobs into the session by accident, if the above monster were
serializable ? What is the reasoning behind having to use form caching
in
HttpSession...
//markku
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
