- 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
