You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Ma...@documenta.fi on 2004/11/16 16:46:04 UTC
file upload, HttpSession content serialization failure, session size
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: RequestProcessor processRoles question!
Posted by Craig McClanahan <cr...@gmail.com>.
Among other reasons, sending SC_UNAUTHORIZED would trigger the popup
dialog for basic authentication -- that's not what we really want to
have happen, since we know who the user is; she's just not allowed to
access this particular action.
Craig
On Wed, 17 Nov 2004 16:58:33 +0000, João Vieira da Luz
<jo...@gmail.com> wrote:
> For the first time, in struts application development I'm using roles
> attribute from action-mapping.
>
> I found something weird in method processRoles on the class RequestProcessor:
> response.sendError(HttpServletResponse.SC_BAD_REQUEST,
> getInternal().getMessage("notAuthorized",
> mapping.getPath()));
>
> IMHO it will be more correct to send a HttpServletResponse.SC_UNAUTHORIZED.
>
> BTW, I'm using struts 1.1
>
> What do you think?
> What was the reason to send BAD_REQUEST (error code 400) instead of
> UNAUTHORIZED (error code 401)?
>
> Thanks in advance,
> João
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RequestProcessor processRoles question!
Posted by João Vieira da Luz <jo...@gmail.com>.
For the first time, in struts application development I'm using roles
attribute from action-mapping.
I found something weird in method processRoles on the class RequestProcessor:
response.sendError(HttpServletResponse.SC_BAD_REQUEST,
getInternal().getMessage("notAuthorized",
mapping.getPath()));
IMHO it will be more correct to send a HttpServletResponse.SC_UNAUTHORIZED.
BTW, I'm using struts 1.1
What do you think?
What was the reason to send BAD_REQUEST (error code 400) instead of
UNAUTHORIZED (error code 401)?
Thanks in advance,
João
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: file upload, HttpSession content serialization failure, session
size
Posted by Bill Siggelkow <bi...@bellsouth.net>.
OutputStreams are not serializable; in other words, when the object is
deserialized chances are it cannot be restored the state it was in when
it was serialized. Probably the best way to solve your problem is to to
mark the field that holds the OutputStream (FormFile?) as "transient".
Markku.Luotamo@documenta.fi wrote:
> - 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.
>
>
> Markku.Luotamo@documenta.fi 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: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: file upload, HttpSession content serialization failure, session size
Posted by Ma...@documenta.fi.
- 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.
Markku.Luotamo@documenta.fi 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org