The <action scope="session" ... /> property is meant to refer to the ActionForm for that mapping and should not affect any object represented in the struts-config. To have the ActionForms default to request scope, you can specify another classname in the action-mappings element. The RequestActionMapping class is provided for that purpose.
AFAIK, the only objects Struts would ever store in the session are a session-scoped ActionForm, a Locale object, and a session-scoped exception error. The other objects specified by the struts-config should be stored in application scope and shared by all clients.
I believe what you are looking at is a pointer from the DynaActionForm to the shared configuration in application scope. If we are somehow copying the Struts Configuration into the session scope, then, yes, I believe that would be a bug ... or at least a feature that needs to be reconsidered =:0)
-Ted.
Maya Retzlaff wrote:
Dear Developers,
I've been lurking on the developers list for a while and submitted the
questions/problems below to the struts-user list. Unfortunately I haven't
gotten a reply, and I was recommended to try the developers list. I hope,
that posting this list to the developer list, is not to big a breech of
protocol.
Best regards
/Maya Retzlaff
ps. Due to time differences I might be a bit slow in replying ds.
-----Original Message----- From: Maya Retzlaff [mailto:[EMAIL PROTECTED] Sent: den 28 juli 2003 21:19 To: 'Struts Users Mailing List' Subject: RE: Memory consumption 1.1 b3 vs. 1.1 final
Hi,
Unfortunate no one replied. But I'll try again with more information.
After a bit more debugging, when using the debugger see screen shot. http://maya.retzlaff.se/debugScreenShot.png, sorry couldn't export to text.
Its a bit censored.
This means that the whole struts-config.xml (a HashMap with 127 elements) is
saved in the session for every user when <action scope="session"> is set in
struts-config.xml. For us with the memory restrictions we face, the 50k that
the strutsconfig takes in memory is very severe. If this is a conscious design description, it would be very good to hear the
reasons. If not could we in anyway work with someone to help debug it so we could
submit a patch?
Now when comparing the source files for the different releases we can't find
anything significantly different in any of these classes. And finding where
moduleconfig gets set into the FormBeanConfig is untraceable. Is it done in
apache.commons?
A search in bugzilla either hasn't yielded anything either, regrettably
We are on a schedule and need to have this solved on Weds, otherwise we need
to go back to the 1.1 b3 release. Obviously we would prefer to use the
stable 1.1 release.
Help would be very much appreciated.
/Maya
-----Original Message----- From: Maya Retzlaff [mailto:[EMAIL PROTECTED] Sent: den 25 juli 2003 19:57 To: 'Struts Users Mailing List' Subject: Memory consumption 1.1 b3 vs. 1.1 final
Hi,
Me and my colleagues are developing a web application in an environment of
very strict memory limitations, for instance the session size per user is
limited to 15k. If we go over the limit the application fails. Its out of
our control
unfortunately.
We are subclassing the DynaActionForm for use in our own forms, when this
form is saved to the session, which we do in rare cases, it uses quite a lot
of memory.
We were previously running on jakarta-struts-1.1-b3 from October release
which caused no problem. Below is a comparison of the memory consumption
with 1.1 Final on the _same_ form
Running on the same version of tomcat:
1.1 b3 2344 k 1.1 Final 76624 k
When debugging (serializing and back) we found that the DynaAction uses
FormBeanConfig which in turns refer to ModuleConfigImp which keeps a
reference to the complete struts config file. This in our case, where we
don't use modules but have all the config info in one class, takes quite a
lot of memory.
In comparing directories, and source from the two different releases nothing
obvious appears.
The memory problem still appears on our wml interface site where we
ourselves implemented the "front end" bits of struts instead of struts-html,
we can rule out a fair chunk of the struts classes.
Has anyone else come across the problem? Any suggestions on how we could
reduce the size.
We'd be very grateful for help as the release date for the project we are
working is starting to get uncomfortably close.
Best Regards /Maya
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Ted Husted, Junit in Action - <http://www.manning.com/massol/>, Struts in Action - <http://husted.com/struts/book.html>, JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
