RE: Single ActionForm accross multiple Actions
Interesting topic. I am new to server clustering so I'd like to discuss about how fail-over get implemented in a clustering env. I understand any ActionForms and custom data objects in the session need to be serializable, so in case one node server fails, all the information can be serialized and recreated in another node server. And the end user will not aware of this fail over happened. But when does the Serialization happen? Think of the extreme case of a fatal memory error in one node server, if the session data does not get serialized before, then this node server may not have the chance to do the serialization. So if my logic is correct, the server need to serialize the session object often enough with each http request, to be safe. Then if your session object is big, there will be a lot of IO involved to do the serialization. That may be the reason IBM suggest to keep session object under 4K. Am I right on this? Thanks, Yuanbo -Original Message- From: Frank Zammetti [mailto:[EMAIL PROTECTED] Sent: Thursday, June 10, 2004 9:42 AM To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions That's good info, thank you! I was suspecting this was an issue that arises in a distributed environment and probably isn't quite as critical on a single server. I think the thought of keeping session as small as possible is ALWAYS a good idea, but my suspicion is that it only really becomes very important with multiple servers involved, as you point out. Your point about session vs. cost of back-end work is important, and was the reason I personally did what I did in the app I'm thinking of... The back-end calls in a couple of cases were fairly expensive, and keeping the data in session improved performance noticably. However I may now in fact be moving into a distributed environment, so I may have to do some refactoring to cut down session size Interestingly, using the code from Ken yesterday I discovered that my user's session in this app average 8k-10k, but peak up to 25k-30k at certain points... I also discovered that I'm never clearing out that session info to get it back down to 10k. I thought I was all this time. Leaving that info there doesn't affect the functioning of the application in any way because it's constantly being overwritten with fresh data, but the fact is that I really should clear it out to reduce the size of session when possible. Fortunately there is one place in the app that makes perfect sense to do this, the app kind of flows through this one spot, so that's a nice thing. I'm going to be looking into cutting out some of that data, but I already know there's not much I can do in that regard. Frank From: Jesse Alexander (KXT) [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Thu, 10 Jun 2004 09:01:57 +0200 As far as I know... The recommendation to keep the session below the 4-5 kB limit comes from clustering. When you build a cluster for your webapp and specify session failover, meaning that a session should be taken over by a running instance in the cluster if the original instance crashes, then the session must be replicated everytime it changes to all instances in the cluster. This session-replication usually scales well, IF the information to be broadcasted does not exceed 4 kB. At least that's what I was taught. I operate in WLS-area, but I believe WS is behaving similar in that area (everybody is cooking with the same water ;-) ). I know of applications that scale well with session up into the MB-area! Their problem is not the memory on the mid-tier server. You just must give them all the memory you can buy... These applications cache some data they must request from a backend. And the backend-mechanism make it perform and scale better when the data is cached in the session. But these apps are special cases!!! (Cost of calling the backend must also be considered...). hth Alexander -Original Message- From: Frank Zammetti [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 9. Juni 2004 20:02 To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions I had that thought too, but I don't know enough about WebSphere to know if it does that all the time... I know that I just installed 5.0 on a test box and didn't have to set up a database or anything, so unless it (a) set one up itself and is using it under the hood, or (b) is persisting to the file system, which I tend to doubt, then I'm thinking along the same lines as you I think, which is to say that this recommendation, while probably valid all the time, doesn't carry the same weight if session is in-memory only. Can anyone shed more light on this? Frank From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED
RE: Single ActionForm accross multiple Actions
Usually what happens in a clustered environment, whether failover is involved or not, is that all information that would otherwise be stored in memory gets saved to a database, or some other persistent storage mechanism, that all servers have access to. In many cases this is a database that all servers share. Some servers will simply synchronize between themselves without a shared persistence mechanism. So for instance when you add an attribute to a sesison object on one server, it will send that information to all the other servers in the cluster and they store it as well. Then, if a failover ocurrs (or if you are just balancing load between the servers), they all have the same redundant data on them, so any server can take the place of any other at any point in time. The same is true if they are all sharing a database instance. All of this happens independant of the application, except to the extent that your objects to store need to be serializable as you said. I have heard of some cases where servers will expose information to your app, like what node of a cluster you are running on, and that is sometimes important to know. Generally speaking though, unless you have a reason to do otherwise, your app should be written without concern for clustering or failover, let it be handled at the app server level. Frank From: Wang, Yuanbo [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Fri, 11 Jun 2004 10:59:19 -0500 Interesting topic. I am new to server clustering so I'd like to discuss about how fail-over get implemented in a clustering env. I understand any ActionForms and custom data objects in the session need to be serializable, so in case one node server fails, all the information can be serialized and recreated in another node server. And the end user will not aware of this fail over happened. But when does the Serialization happen? Think of the extreme case of a fatal memory error in one node server, if the session data does not get serialized before, then this node server may not have the chance to do the serialization. So if my logic is correct, the server need to serialize the session object often enough with each http request, to be safe. Then if your session object is big, there will be a lot of IO involved to do the serialization. That may be the reason IBM suggest to keep session object under 4K. Am I right on this? Thanks, Yuanbo -Original Message- From: Frank Zammetti [mailto:[EMAIL PROTECTED] Sent: Thursday, June 10, 2004 9:42 AM To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions That's good info, thank you! I was suspecting this was an issue that arises in a distributed environment and probably isn't quite as critical on a single server. I think the thought of keeping session as small as possible is ALWAYS a good idea, but my suspicion is that it only really becomes very important with multiple servers involved, as you point out. Your point about session vs. cost of back-end work is important, and was the reason I personally did what I did in the app I'm thinking of... The back-end calls in a couple of cases were fairly expensive, and keeping the data in session improved performance noticably. However I may now in fact be moving into a distributed environment, so I may have to do some refactoring to cut down session size Interestingly, using the code from Ken yesterday I discovered that my user's session in this app average 8k-10k, but peak up to 25k-30k at certain points... I also discovered that I'm never clearing out that session info to get it back down to 10k. I thought I was all this time. Leaving that info there doesn't affect the functioning of the application in any way because it's constantly being overwritten with fresh data, but the fact is that I really should clear it out to reduce the size of session when possible. Fortunately there is one place in the app that makes perfect sense to do this, the app kind of flows through this one spot, so that's a nice thing. I'm going to be looking into cutting out some of that data, but I already know there's not much I can do in that regard. Frank From: Jesse Alexander (KXT) [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Thu, 10 Jun 2004 09:01:57 +0200 As far as I know... The recommendation to keep the session below the 4-5 kB limit comes from clustering. When you build a cluster for your webapp and specify session failover, meaning that a session should be taken over by a running instance in the cluster if the original instance crashes, then the session must be replicated everytime it changes to all instances in the cluster. This session-replication usually scales well, IF the information
RE: Single ActionForm accross multiple Actions
As far as I know... The recommendation to keep the session below the 4-5 kB limit comes from clustering. When you build a cluster for your webapp and specify session failover, meaning that a session should be taken over by a running instance in the cluster if the original instance crashes, then the session must be replicated everytime it changes to all instances in the cluster. This session-replication usually scales well, IF the information to be broadcasted does not exceed 4 kB. At least that's what I was taught. I operate in WLS-area, but I believe WS is behaving similar in that area (everybody is cooking with the same water ;-) ). I know of applications that scale well with session up into the MB-area! Their problem is not the memory on the mid-tier server. You just must give them all the memory you can buy... These applications cache some data they must request from a backend. And the backend-mechanism make it perform and scale better when the data is cached in the session. But these apps are special cases!!! (Cost of calling the backend must also be considered...). hth Alexander -Original Message- From: Frank Zammetti [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 9. Juni 2004 20:02 To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions I had that thought too, but I don't know enough about WebSphere to know if it does that all the time... I know that I just installed 5.0 on a test box and didn't have to set up a database or anything, so unless it (a) set one up itself and is using it under the hood, or (b) is persisting to the file system, which I tend to doubt, then I'm thinking along the same lines as you I think, which is to say that this recommendation, while probably valid all the time, doesn't carry the same weight if session is in-memory only. Can anyone shed more light on this? Frank From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Wed, 9 Jun 2004 13:26:40 -0400 http://www.redbooks.ibm.com/redbooks/pdfs/sg246176.pdf I'm not 100% sure, but it seems that the recommendation for session size being 4-5K is targeted to the scenario where the server has to serialize the session for persistence. Dennis Frank Zammetti [EMAIL PROTECTED] 06/09/2004 01:10 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject RE: Single ActionForm accross multiple Actions Very interesting (in a bad way for me!)... does anyone know if there is an easy way to see exactly how big the session object is at any given point in time? Preferably something not specific to WebSphere... is there a method of session I'm unaware of that might help? Frank From: Yulin Zhao [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Wed, 9 Jun 2004 11:57:49 -0500 Regarding WebSphere session performance, IBM redbook sg246176 chapter 15.10 has some details that might help you. We use WAS4 so that's for WAS4. Here is some note from it: In general the best performance will be realized with session objects that are less than 2 KB in size. Once the session object starts to exceed 4-5 KB in size, a significant decrease in performance can be expected. [EMAIL PROTECTED] on 06/09/2004 11:07:58 AM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Yulin Zhao/FBFS) Subject: RE: Single ActionForm accross multiple Actions I wasn't doubting you, as that standard practice rule is fairly well-known outside WebSphere. I think I've generally heard 32K as a limit, but whatever, the point is keep session objects small. What I was asking was if there was some technical limitation in WebSphere I wasn't aware of. I can't go re-architecting this particular application now, so if I'm storing 64K per session I was curious if WebSphere was going to choke on it. I understand the performance implications and the server resource implications, as I did when I took this path, but I wasn't sure if there was something more I wasn't aware of. Thanks for the lnik in any case. Although it's 95% stuff I knew already (a couple of EJB points I hadn't considered), it's something I can pass out to the more junior members of my staff. Frank From: Enrique Medina [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Wed, 09 Jun 2004 16:45:04 +0200 I am sure about this problem, believe me. See http://www-3.ibm.com/software/webservers/appserv/ws_bestpractices.pdf From: Frank Zammetti [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED
RE: Single ActionForm accross multiple Actions
I've been reading this thread of discussion and one question arises in my
mind that you probably has not taken into consideration.
Is there any limit with session management in your application server? I
mean, Websphere, for example, warns you about storing more than 16K in
session.
To bypass this problem, there is a good alternative (to the best of my
knowledge): create a Map where keys would be session IDs and values would be
data (this would lead to the need of creating a wrapper for all your data).
Then, this Map could be placed in application context, servlet context (in
case of Struts which only uses one ActionServlet) or even as a static Map
shared by all users in the application server (of course, with no clustering
at all).
I would be delighted to hear some comments and suggestions in this solution.
Enrique Medina.
From: Frank Zammetti [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE: Single ActionForm accross multiple Actions
Date: Tue, 08 Jun 2004 22:02:01 -0400
MIME-Version: 1.0
X-Originating-IP: [68.81.51.228]
X-Originating-Email: [EMAIL PROTECTED]
X-Sender: [EMAIL PROTECTED]
Received: from mail.apache.org ([209.237.227.199]) by mc3-f6.hotmail.com
with Microsoft SMTPSVC(5.0.2195.6824); Tue, 8 Jun 2004 19:02:13 -0700
Received: (qmail 97286 invoked by uid 500); 9 Jun 2004 02:02:37 -
Received: (qmail 97272 invoked by uid 99); 9 Jun 2004 02:02:36 -
Received: from [64.4.27.85] (HELO hotmail.com) (64.4.27.85) by apache.org
(qpsmtpd/0.27.1) with ESMTP; Tue, 08 Jun 2004 19:02:36 -0700
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
Tue, 8 Jun 2004 19:02:01 -0700
Received: from 68.81.51.228 by by8fd.bay8.hotmail.msn.com with HTTP;Wed, 09
Jun 2004 02:02:01 GMT
X-Message-Info: JGTYoYF78jEng6W3tuLSY7svF94DHMWf
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Unsubscribe: mailto:[EMAIL PROTECTED]
List-Subscribe: mailto:[EMAIL PROTECTED]
List-Help: mailto:[EMAIL PROTECTED]
List-Post: mailto:[EMAIL PROTECTED]
List-Id: Struts Users Mailing List user.struts.apache.org
Delivered-To: mailing list [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
X-OriginalArrivalTime: 09 Jun 2004 02:02:01.0481 (UTC)
FILETIME=[C0FB5790:01C44DC5]
X-Virus-Checked: Checked
Return-Path: [EMAIL PROTECTED]
You can set the scope attribute of your action mappings to session, then
you don't have to do the code you have below. The form instance that is
passed into execute() will either be what was in session, or a newly
created one.
I'm not sure about the answer to the second part of your question, but I'm
about 99.99% sure you can still use it (anyone else verify?)
Frank
From: Kunal H. Parikh [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
Subject: RE: Single ActionForm accross multiple Actions
Date: Wed, 9 Jun 2004 10:34:27 +1000
Great .. thanks for all the responses...
I think I will go with the ActionForm stored in session-scope.
Just wanting to confirm, that I will need to perform the following code
changes:
==
public ActionForward execute( ActionMapping actionMapping, ActionForm
actionForm, HttpServletRequest httpServletRequest, HttpServletResponse
httpServletResponse ) throws Exception
{
actionForm = httpServletRequest.getSession().getAttribute(myForm);
// ...
// normal code follows!!!
}
==
Also, would I be correct in saying that I will be unable to use the
ValidatorActionForm.
TIA,
Kunal
-Original Message-
From: Frank Zammetti [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 8 June 2004 23:21
To: [EMAIL PROTECTED]
Subject: RE: Single ActionForm accross multiple Actions
This is more or less what a session-scope ActionForm is for. As long as
the
ActionForm class contains all the properties and methods for all the
screen
it will service, just putting it in session I think is your best bet. As
someone else said, hidden form fields are your other choice. Actually,
you
could also store the data temporarily to a database, but if you would even
consider that, session is really the right answer.
Frank
From: Kunal H. Parikh [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
Subject: Single ActionForm accross multiple Actions
Date: Tue, 8 Jun 2004 12:08:25 +1000
Hi All!
I want to maintain a single ActionForm across multiple Actions.
I want to get the info from the user in a step-by-step manner, but only
wanna talk to the SessionBean at the end when they hit confirm.
The alternative that I can think of is writing a JavaBean with all the
properties, and pass the JavaBean around as a session attribute.
Any one have a better solution ?
TIA,
Kunal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e
RE: Single ActionForm accross multiple Actions
Do you know the rational behind that WebSphere warning? I mean, the obvious
answer is it uses up server resources and will use more as load increases,
but is there another reason you know of? I ask because I have an
application where we store quite considerably more than 16K without any
problem. We're currently running it under Tomcat but are migrating to
WebSphere 5, so this caught my attention.
Frank
From: Enrique Medina [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE: Single ActionForm accross multiple Actions
Date: Wed, 09 Jun 2004 09:57:02 +0200
I've been reading this thread of discussion and one question arises in my
mind that you probably has not taken into consideration.
Is there any limit with session management in your application server? I
mean, Websphere, for example, warns you about storing more than 16K in
session.
To bypass this problem, there is a good alternative (to the best of my
knowledge): create a Map where keys would be session IDs and values would
be data (this would lead to the need of creating a wrapper for all your
data). Then, this Map could be placed in application context, servlet
context (in case of Struts which only uses one ActionServlet) or even as a
static Map shared by all users in the application server (of course, with
no clustering at all).
I would be delighted to hear some comments and suggestions in this
solution.
Enrique Medina.
From: Frank Zammetti [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE: Single ActionForm accross multiple Actions
Date: Tue, 08 Jun 2004 22:02:01 -0400
MIME-Version: 1.0
X-Originating-IP: [68.81.51.228]
X-Originating-Email: [EMAIL PROTECTED]
X-Sender: [EMAIL PROTECTED]
Received: from mail.apache.org ([209.237.227.199]) by mc3-f6.hotmail.com
with Microsoft SMTPSVC(5.0.2195.6824); Tue, 8 Jun 2004 19:02:13 -0700
Received: (qmail 97286 invoked by uid 500); 9 Jun 2004 02:02:37 -
Received: (qmail 97272 invoked by uid 99); 9 Jun 2004 02:02:36 -
Received: from [64.4.27.85] (HELO hotmail.com) (64.4.27.85) by apache.org
(qpsmtpd/0.27.1) with ESMTP; Tue, 08 Jun 2004 19:02:36 -0700
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
Tue, 8 Jun 2004 19:02:01 -0700
Received: from 68.81.51.228 by by8fd.bay8.hotmail.msn.com with HTTP;Wed,
09 Jun 2004 02:02:01 GMT
X-Message-Info: JGTYoYF78jEng6W3tuLSY7svF94DHMWf
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Unsubscribe: mailto:[EMAIL PROTECTED]
List-Subscribe: mailto:[EMAIL PROTECTED]
List-Help: mailto:[EMAIL PROTECTED]
List-Post: mailto:[EMAIL PROTECTED]
List-Id: Struts Users Mailing List user.struts.apache.org
Delivered-To: mailing list [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
X-OriginalArrivalTime: 09 Jun 2004 02:02:01.0481 (UTC)
FILETIME=[C0FB5790:01C44DC5]
X-Virus-Checked: Checked
Return-Path: [EMAIL PROTECTED]
You can set the scope attribute of your action mappings to session, then
you don't have to do the code you have below. The form instance that is
passed into execute() will either be what was in session, or a newly
created one.
I'm not sure about the answer to the second part of your question, but I'm
about 99.99% sure you can still use it (anyone else verify?)
Frank
From: Kunal H. Parikh [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
Subject: RE: Single ActionForm accross multiple Actions
Date: Wed, 9 Jun 2004 10:34:27 +1000
Great .. thanks for all the responses...
I think I will go with the ActionForm stored in session-scope.
Just wanting to confirm, that I will need to perform the following code
changes:
==
public ActionForward execute( ActionMapping actionMapping, ActionForm
actionForm, HttpServletRequest httpServletRequest, HttpServletResponse
httpServletResponse ) throws Exception
{
actionForm = httpServletRequest.getSession().getAttribute(myForm);
// ...
// normal code follows!!!
}
==
Also, would I be correct in saying that I will be unable to use the
ValidatorActionForm.
TIA,
Kunal
-Original Message-
From: Frank Zammetti [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 8 June 2004 23:21
To: [EMAIL PROTECTED]
Subject: RE: Single ActionForm accross multiple Actions
This is more or less what a session-scope ActionForm is for. As long as
the
ActionForm class contains all the properties and methods for all the
screen
it will service, just putting it in session I think is your best bet. As
someone else said, hidden form fields are your other choice. Actually,
you
could also store the data temporarily to a database, but if you would
even
consider that, session is really the right answer.
Frank
From: Kunal H. Parikh [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED
RE: Single ActionForm accross multiple Actions
I wasn't doubting you, as that standard practice rule is fairly well-known outside WebSphere. I think I've generally heard 32K as a limit, but whatever, the point is keep session objects small. What I was asking was if there was some technical limitation in WebSphere I wasn't aware of. I can't go re-architecting this particular application now, so if I'm storing 64K per session I was curious if WebSphere was going to choke on it. I understand the performance implications and the server resource implications, as I did when I took this path, but I wasn't sure if there was something more I wasn't aware of. Thanks for the lnik in any case. Although it's 95% stuff I knew already (a couple of EJB points I hadn't considered), it's something I can pass out to the more junior members of my staff. Frank From: Enrique Medina [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Wed, 09 Jun 2004 16:45:04 +0200 I am sure about this problem, believe me. See http://www-3.ibm.com/software/webservers/appserv/ws_bestpractices.pdf From: Frank Zammetti [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Wed, 09 Jun 2004 09:25:16 -0400 MIME-Version: 1.0 X-Originating-IP: [66.98.131.150] X-Originating-Email: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] Received: from mail.apache.org ([209.237.227.199]) by mc9-f7.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Wed, 9 Jun 2004 06:27:06 -0700 Received: (qmail 19779 invoked by uid 500); 9 Jun 2004 13:27:00 - Received: (qmail 19670 invoked by uid 99); 9 Jun 2004 13:26:59 - Received: from [64.4.27.56] (HELO hotmail.com) (64.4.27.56) by apache.org (qpsmtpd/0.27.1) with ESMTP; Wed, 09 Jun 2004 06:26:59 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 9 Jun 2004 06:25:16 -0700 Received: from 66.98.131.150 by by8fd.bay8.hotmail.msn.com with HTTP;Wed, 09 Jun 2004 13:25:16 GMT X-Message-Info: JGTYoYF78jGOA3bTrliIqk5vRqlH20u2 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Post: mailto:[EMAIL PROTECTED] List-Id: Struts Users Mailing List user.struts.apache.org Delivered-To: mailing list [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] X-OriginalArrivalTime: 09 Jun 2004 13:25:16.0563 (UTC) FILETIME=[33F46E30:01C44E25] X-Virus-Checked: Checked Return-Path: [EMAIL PROTECTED] Do you know the rational behind that WebSphere warning? I mean, the obvious answer is it uses up server resources and will use more as load increases, but is there another reason you know of? I ask because I have an application where we store quite considerably more than 16K without any problem. We're currently running it under Tomcat but are migrating to WebSphere 5, so this caught my attention. Frank From: Enrique Medina [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Wed, 09 Jun 2004 09:57:02 +0200 I've been reading this thread of discussion and one question arises in my mind that you probably has not taken into consideration. Is there any limit with session management in your application server? I mean, Websphere, for example, warns you about storing more than 16K in session. To bypass this problem, there is a good alternative (to the best of my knowledge): create a Map where keys would be session IDs and values would be data (this would lead to the need of creating a wrapper for all your data). Then, this Map could be placed in application context, servlet context (in case of Struts which only uses one ActionServlet) or even as a static Map shared by all users in the application server (of course, with no clustering at all). I would be delighted to hear some comments and suggestions in this solution. Enrique Medina. From: Frank Zammetti [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Tue, 08 Jun 2004 22:02:01 -0400 MIME-Version: 1.0 X-Originating-IP: [68.81.51.228] X-Originating-Email: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] Received: from mail.apache.org ([209.237.227.199]) by mc3-f6.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Tue, 8 Jun 2004 19:02:13 -0700 Received: (qmail 97286 invoked by uid 500); 9 Jun 2004 02:02:37 - Received: (qmail 97272 invoked by uid 99); 9 Jun 2004 02:02:36 - Received: from [64.4.27.85] (HELO hotmail.com) (64.4.27.85) by apache.org (qpsmtpd/0.27.1) with ESMTP; Tue, 08 Jun 2004 19:02:36 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 8 Jun 2004 19:02:01 -0700 Received: from
RE: Single ActionForm accross multiple Actions
Regarding WebSphere session performance, IBM redbook sg246176 chapter 15.10 has some details that might help you. We use WAS4 so that's for WAS4. Here is some note from it: In general the best performance will be realized with session objects that are less than 2 KB in size. Once the session object starts to exceed 4-5 KB in size, a significant decrease in performance can be expected. [EMAIL PROTECTED] on 06/09/2004 11:07:58 AM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Yulin Zhao/FBFS) Subject: RE: Single ActionForm accross multiple Actions I wasn't doubting you, as that standard practice rule is fairly well-known outside WebSphere. I think I've generally heard 32K as a limit, but whatever, the point is keep session objects small. What I was asking was if there was some technical limitation in WebSphere I wasn't aware of. I can't go re-architecting this particular application now, so if I'm storing 64K per session I was curious if WebSphere was going to choke on it. I understand the performance implications and the server resource implications, as I did when I took this path, but I wasn't sure if there was something more I wasn't aware of. Thanks for the lnik in any case. Although it's 95% stuff I knew already (a couple of EJB points I hadn't considered), it's something I can pass out to the more junior members of my staff. Frank From: Enrique Medina [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Wed, 09 Jun 2004 16:45:04 +0200 I am sure about this problem, believe me. See http://www-3.ibm.com/software/webservers/appserv/ws_bestpractices.pdf From: Frank Zammetti [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Wed, 09 Jun 2004 09:25:16 -0400 MIME-Version: 1.0 X-Originating-IP: [66.98.131.150] X-Originating-Email: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] Received: from mail.apache.org ([209.237.227.199]) by mc9-f7.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Wed, 9 Jun 2004 06:27:06 -0700 Received: (qmail 19779 invoked by uid 500); 9 Jun 2004 13:27:00 - Received: (qmail 19670 invoked by uid 99); 9 Jun 2004 13:26:59 - Received: from [64.4.27.56] (HELO hotmail.com) (64.4.27.56) by apache.org (qpsmtpd/0.27.1) with ESMTP; Wed, 09 Jun 2004 06:26:59 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 9 Jun 2004 06:25:16 -0700 Received: from 66.98.131.150 by by8fd.bay8.hotmail.msn.com with HTTP;Wed, 09 Jun 2004 13:25:16 GMT X-Message-Info: JGTYoYF78jGOA3bTrliIqk5vRqlH20u2 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Post: mailto:[EMAIL PROTECTED] List-Id: Struts Users Mailing List user.struts.apache.org Delivered-To: mailing list [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] X-OriginalArrivalTime: 09 Jun 2004 13:25:16.0563 (UTC) FILETIME=[33F46E30:01C44E25] X-Virus-Checked: Checked Return-Path: [EMAIL PROTECTED] Do you know the rational behind that WebSphere warning? I mean, the obvious answer is it uses up server resources and will use more as load increases, but is there another reason you know of? I ask because I have an application where we store quite considerably more than 16K without any problem. We're currently running it under Tomcat but are migrating to WebSphere 5, so this caught my attention. Frank From: Enrique Medina [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Wed, 09 Jun 2004 09:57:02 +0200 I've been reading this thread of discussion and one question arises in my mind that you probably has not taken into consideration. Is there any limit with session management in your application server? I mean, Websphere, for example, warns you about storing more than 16K in session. To bypass this problem, there is a good alternative (to the best of my knowledge): create a Map where keys would be session IDs and values would be data (this would lead to the need of creating a wrapper for all your data). Then, this Map could be placed in application context, servlet context (in case of Struts which only uses one ActionServlet) or even as a static Map shared by all users in the application server (of course, with no clustering at all). I would be delighted to hear some comments and suggestions in this solution. Enrique Medina. From: Frank Zammetti [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Tue, 08 Jun 2004 22:02:01 -0400 MIME-Version: 1.0 X-Originating-IP: [68.81.51.228] X-Originating
RE: Single ActionForm accross multiple Actions
Very interesting (in a bad way for me!)... does anyone know if there is an easy way to see exactly how big the session object is at any given point in time? Preferably something not specific to WebSphere... is there a method of session I'm unaware of that might help? Frank From: Yulin Zhao [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Wed, 9 Jun 2004 11:57:49 -0500 Regarding WebSphere session performance, IBM redbook sg246176 chapter 15.10 has some details that might help you. We use WAS4 so that's for WAS4. Here is some note from it: In general the best performance will be realized with session objects that are less than 2 KB in size. Once the session object starts to exceed 4-5 KB in size, a significant decrease in performance can be expected. [EMAIL PROTECTED] on 06/09/2004 11:07:58 AM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Yulin Zhao/FBFS) Subject: RE: Single ActionForm accross multiple Actions I wasn't doubting you, as that standard practice rule is fairly well-known outside WebSphere. I think I've generally heard 32K as a limit, but whatever, the point is keep session objects small. What I was asking was if there was some technical limitation in WebSphere I wasn't aware of. I can't go re-architecting this particular application now, so if I'm storing 64K per session I was curious if WebSphere was going to choke on it. I understand the performance implications and the server resource implications, as I did when I took this path, but I wasn't sure if there was something more I wasn't aware of. Thanks for the lnik in any case. Although it's 95% stuff I knew already (a couple of EJB points I hadn't considered), it's something I can pass out to the more junior members of my staff. Frank From: Enrique Medina [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Wed, 09 Jun 2004 16:45:04 +0200 I am sure about this problem, believe me. See http://www-3.ibm.com/software/webservers/appserv/ws_bestpractices.pdf From: Frank Zammetti [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Wed, 09 Jun 2004 09:25:16 -0400 MIME-Version: 1.0 X-Originating-IP: [66.98.131.150] X-Originating-Email: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] Received: from mail.apache.org ([209.237.227.199]) by mc9-f7.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Wed, 9 Jun 2004 06:27:06 -0700 Received: (qmail 19779 invoked by uid 500); 9 Jun 2004 13:27:00 - Received: (qmail 19670 invoked by uid 99); 9 Jun 2004 13:26:59 - Received: from [64.4.27.56] (HELO hotmail.com) (64.4.27.56) by apache.org (qpsmtpd/0.27.1) with ESMTP; Wed, 09 Jun 2004 06:26:59 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 9 Jun 2004 06:25:16 -0700 Received: from 66.98.131.150 by by8fd.bay8.hotmail.msn.com with HTTP;Wed, 09 Jun 2004 13:25:16 GMT X-Message-Info: JGTYoYF78jGOA3bTrliIqk5vRqlH20u2 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Post: mailto:[EMAIL PROTECTED] List-Id: Struts Users Mailing List user.struts.apache.org Delivered-To: mailing list [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] X-OriginalArrivalTime: 09 Jun 2004 13:25:16.0563 (UTC) FILETIME=[33F46E30:01C44E25] X-Virus-Checked: Checked Return-Path: [EMAIL PROTECTED] Do you know the rational behind that WebSphere warning? I mean, the obvious answer is it uses up server resources and will use more as load increases, but is there another reason you know of? I ask because I have an application where we store quite considerably more than 16K without any problem. We're currently running it under Tomcat but are migrating to WebSphere 5, so this caught my attention. Frank From: Enrique Medina [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Wed, 09 Jun 2004 09:57:02 +0200 I've been reading this thread of discussion and one question arises in my mind that you probably has not taken into consideration. Is there any limit with session management in your application server? I mean, Websphere, for example, warns you about storing more than 16K in session. To bypass this problem, there is a good alternative (to the best of my knowledge): create a Map where keys would be session IDs and values would be data (this would lead to the need of creating a wrapper for all your data). Then, this Map could be placed in application context, servlet context (in case of Struts which
RE: Single ActionForm accross multiple Actions
We didn't find anything automatic for showing whats in session. We created a JSP which iterated through the session attributes. For each object, determined if its serilizable and if so convert it into a byte array output stream. We get the size of the stream and also dumped the content to the jsp. We added the size up to get total size for session. It also helped us to determine what was not implementing the serializable interface for resolving clustering issues, etc. -Original Message- From: Frank Zammetti [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 09, 2004 2:02 PM To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions I had that thought too, but I don't know enough about WebSphere to know if it does that all the time... I know that I just installed 5.0 on a test box and didn't have to set up a database or anything, so unless it (a) set one up itself and is using it under the hood, or (b) is persisting to the file system, which I tend to doubt, then I'm thinking along the same lines as you I think, which is to say that this recommendation, while probably valid all the time, doesn't carry the same weight if session is in-memory only. Can anyone shed more light on this? Frank From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Wed, 9 Jun 2004 13:26:40 -0400 http://www.redbooks.ibm.com/redbooks/pdfs/sg246176.pdf I'm not 100% sure, but it seems that the recommendation for session size being 4-5K is targeted to the scenario where the server has to serialize the session for persistence. Dennis Frank Zammetti [EMAIL PROTECTED] 06/09/2004 01:10 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject RE: Single ActionForm accross multiple Actions Very interesting (in a bad way for me!)... does anyone know if there is an easy way to see exactly how big the session object is at any given point in time? Preferably something not specific to WebSphere... is there a method of session I'm unaware of that might help? Frank From: Yulin Zhao [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Wed, 9 Jun 2004 11:57:49 -0500 Regarding WebSphere session performance, IBM redbook sg246176 chapter 15.10 has some details that might help you. We use WAS4 so that's for WAS4. Here is some note from it: In general the best performance will be realized with session objects that are less than 2 KB in size. Once the session object starts to exceed 4-5 KB in size, a significant decrease in performance can be expected. [EMAIL PROTECTED] on 06/09/2004 11:07:58 AM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Yulin Zhao/FBFS) Subject: RE: Single ActionForm accross multiple Actions I wasn't doubting you, as that standard practice rule is fairly well-known outside WebSphere. I think I've generally heard 32K as a limit, but whatever, the point is keep session objects small. What I was asking was if there was some technical limitation in WebSphere I wasn't aware of. I can't go re-architecting this particular application now, so if I'm storing 64K per session I was curious if WebSphere was going to choke on it. I understand the performance implications and the server resource implications, as I did when I took this path, but I wasn't sure if there was something more I wasn't aware of. Thanks for the lnik in any case. Although it's 95% stuff I knew already (a couple of EJB points I hadn't considered), it's something I can pass out to the more junior members of my staff. Frank From: Enrique Medina [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Wed, 09 Jun 2004 16:45:04 +0200 I am sure about this problem, believe me. See http://www-3.ibm.com/software/webservers/appserv/ws_bestpractices.pdf From: Frank Zammetti [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Single ActionForm accross multiple Actions Date: Wed, 09 Jun 2004 09:25:16 -0400 MIME-Version: 1.0 X-Originating-IP: [66.98.131.150] X-Originating-Email: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] Received: from mail.apache.org ([209.237.227.199]) by mc9-f7.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Wed, 9 Jun 2004 06:27:06 -0700 Received: (qmail 19779 invoked by uid 500); 9 Jun 2004 13:27:00 - Received: (qmail 19670 invoked by uid 99); 9 Jun 2004 13:26:59 - Received: from [64.4.27.56] (HELO hotmail.com) (64.4.27.56
RE: Single ActionForm accross multiple Actions
We created a JSP and one utility class with a couple of methods. This
probably could be improved but it gets the job done for us.
I was copying and pasting the pertinent code. If I am missing something just
holler back but hopefully this gets you started.
JSP as follows(sess.jsp):
===
Session variables:
%
response.setHeader(Pragma, No-cache);
response.setHeader(Cache-Control, no-cache);
Enumeration enum = session.getAttributeNames();
String name = null;
Object obj = null;
String serialOut;
String SIZE_DELIMITER = size=;
int sizeIndex;
int objSize;
int totalSize = 0;
%
br
%
while(enum.hasMoreElements()) {
name = (String)enum.nextElement();
obj = session.getAttribute(name);
serialOut = com.mycompany.YourClass.serializiableTest(obj);
if ((sizeIndex = serialOut.lastIndexOf(SIZE_DELIMITER)) 0) {
objSize =
Integer.parseInt(serialOut.substring(sizeIndex+SIZE_DELIMITER.length(),
serialOut.lastIndexOf(')')));
totalSize += objSize;
}
response.getWriter().println( b + name + /b - +
obj + + serialOut);
%
br
%
}
response.getWriter().println(brbTotal Session Size: +
totalSize); %
===
com.mycompany.YourClass methods needed:
===
...
import java.util.*;
import java.io.*;
import java.lang.reflect.*;
import java.security.AccessController;
import java.security.PrivilegedAction;
public static String serializiableTest(Object obj) {
String ans = ok;
if (obj == null) {
return Object is null;
} else {
try {
ByteArrayOutputStream bastream = new
ByteArrayOutputStream();
ObjectOutputStream p = new ObjectOutputStream(bastream);
p.writeObject(obj);
ans = OK (size= + bastream.size() + );
} catch (NotSerializableException ex) {
Field[] fields = obj.getClass().getDeclaredFields();
ans = NOT SERIALIZABLE (fields= + fields + );
ex.printStackTrace();
Object fldObj = null;
if (fields != null (fields.length 0)) {
StringBuffer sb = new StringBuffer(\n + ans + [);
for (int i = 0; i fields.length; i++) {
sb.append(fields[i].getName());
try {
if (obj != null) {
fldObj = getFieldWithPrivilege(fields[i],
obj);
}
sb.append(::);
if (fldObj == null) {
sb.append(field null);
} else {
sb.append(serializiableTest(fldObj));
}
} catch (IllegalArgumentException aex) {
sb.append(::);
sb.append(ILLEGAL ARGUMENT EXCEPTION);
}
if (i != fields.length - 1) {
sb.append('\n');
}
}
sb.append(]);
ans = sb.toString();
}
} catch (Exception ex) {
ans = EXCEPTION: + ex.getMessage();
}
}
return obj.getClass().getName() + is + ans;
}
static Object getFieldWithPrivilege(Field fld, Object obj) {
final Object obj2 = obj;
final Field fld2 = fld;
return AccessController.doPrivileged(
new PrivilegedAction() {
/**
* Main processing method for the Validator object
*
[EMAIL PROTECTED] Description of the Returned Value
*/
public Object run() {
try {
return fld2.get(obj2);
} catch (IllegalAccessException ex) {
ex.printStackTrace();
return null;
}
}
}
);
}
...
===
-Original Message-
From: Frank Zammetti [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 09, 2004 2:36 PM
To: [EMAIL PROTECTED]
Subject: RE: Single ActionForm accross multiple Actions
Any chance you could pass that JSP along? Sounds like something I could
write in a few minutes, but better to only take a few seconds if you can
send it to me :)
Frank
From: Linck, Ken [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
Subject: RE: Single ActionForm accross multiple Actions
Date: Wed, 9 Jun 2004 14:31
RE: Single ActionForm accross multiple Actions
Welcome..=P
-Original Message-
From: Frank Zammetti [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 09, 2004 3:34 PM
To: [EMAIL PROTECTED]
Subject: RE: Single ActionForm accross multiple Actions
Thanks a ton Ken, that worked like a charm! I've already added it to my
generic helper class that I reuse in most of my webapps, I just added a
static getSessionSize() method instead of doing it in the JSP so I can call
it from anywhere, as long as I pass it a valid session. This definitely
saved me a ton of time, I appreciate it greatly!
Frank
From: Linck, Ken [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
Subject: RE: Single ActionForm accross multiple Actions
Date: Wed, 9 Jun 2004 15:01:09 -0400
We created a JSP and one utility class with a couple of methods. This
probably could be improved but it gets the job done for us.
I was copying and pasting the pertinent code. If I am missing something
just holler back but hopefully this gets you started.
JSP as follows(sess.jsp):
===
Session variables:
%
response.setHeader(Pragma, No-cache);
response.setHeader(Cache-Control, no-cache);
Enumeration enum = session.getAttributeNames();
String name = null;
Object obj = null;
String serialOut;
String SIZE_DELIMITER = size=;
int sizeIndex;
int objSize;
int totalSize = 0;
%
br
%
while(enum.hasMoreElements()) {
name = (String)enum.nextElement();
obj = session.getAttribute(name);
serialOut = com.mycompany.YourClass.serializiableTest(obj);
if ((sizeIndex = serialOut.lastIndexOf(SIZE_DELIMITER)) 0) {
objSize =
Integer.parseInt(serialOut.substring(sizeIndex+SIZE_DELIMITER.length(),
serialOut.lastIndexOf(')')));
totalSize += objSize;
}
response.getWriter().println( b + name + /b - +
obj + + serialOut);
%
br
%
}
response.getWriter().println(brbTotal Session Size: +
totalSize); % ===
com.mycompany.YourClass methods needed:
===
...
import java.util.*;
import java.io.*;
import java.lang.reflect.*;
import java.security.AccessController;
import java.security.PrivilegedAction;
public static String serializiableTest(Object obj) {
String ans = ok;
if (obj == null) {
return Object is null;
} else {
try {
ByteArrayOutputStream bastream = new
ByteArrayOutputStream();
ObjectOutputStream p = new ObjectOutputStream(bastream);
p.writeObject(obj);
ans = OK (size= + bastream.size() + );
} catch (NotSerializableException ex) {
Field[] fields = obj.getClass().getDeclaredFields();
ans = NOT SERIALIZABLE (fields= + fields + );
ex.printStackTrace();
Object fldObj = null;
if (fields != null (fields.length 0)) {
StringBuffer sb = new StringBuffer(\n + ans + [);
for (int i = 0; i fields.length; i++) {
sb.append(fields[i].getName());
try {
if (obj != null) {
fldObj =
getFieldWithPrivilege(fields[i], obj);
}
sb.append(::);
if (fldObj == null) {
sb.append(field null);
} else {
sb.append(serializiableTest(fldObj));
}
} catch (IllegalArgumentException aex) {
sb.append(::);
sb.append(ILLEGAL ARGUMENT EXCEPTION);
}
if (i != fields.length - 1) {
sb.append('\n');
}
}
sb.append(]);
ans = sb.toString();
}
} catch (Exception ex) {
ans = EXCEPTION: + ex.getMessage();
}
}
return obj.getClass().getName() + is + ans;
}
static Object getFieldWithPrivilege(Field fld, Object obj) {
final Object obj2 = obj;
final Field fld2 = fld;
return AccessController.doPrivileged(
new PrivilegedAction() {
/**
* Main processing method for the Validator object
*
[EMAIL PROTECTED] Description of the Returned Value
*/
public Object run() {
try
Re: Single ActionForm accross multiple Actions
Hidden form variables. Dennis Kunal H. Parikh [EMAIL PROTECTED] 06/07/2004 10:08 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To 'Struts Users Mailing List' [EMAIL PROTECTED] cc Subject Single ActionForm accross multiple Actions Hi All! I want to maintain a single ActionForm across multiple Actions. I want to get the info from the user in a step-by-step manner, but only wanna talk to the SessionBean at the end when they hit confirm. The alternative that I can think of is writing a JavaBean with all the properties, and pass the JavaBean around as a session attribute. Any one have a better solution ? TIA, Kunal - 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]
RE: Single ActionForm accross multiple Actions
This is more or less what a session-scope ActionForm is for. As long as the ActionForm class contains all the properties and methods for all the screen it will service, just putting it in session I think is your best bet. As someone else said, hidden form fields are your other choice. Actually, you could also store the data temporarily to a database, but if you would even consider that, session is really the right answer. Frank From: Kunal H. Parikh [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: Single ActionForm accross multiple Actions Date: Tue, 8 Jun 2004 12:08:25 +1000 Hi All! I want to maintain a single ActionForm across multiple Actions. I want to get the info from the user in a step-by-step manner, but only wanna talk to the SessionBean at the end when they hit confirm. The alternative that I can think of is writing a JavaBean with all the properties, and pass the JavaBean around as a session attribute. Any one have a better solution ? TIA, Kunal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Watch the online reality show Mixed Messages with a friend and enter to win a trip to NY http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Single ActionForm accross multiple Actions
You can set the scope attribute of your action mappings to session, then you
don't have to do the code you have below. The form instance that is passed
into execute() will either be what was in session, or a newly created one.
I'm not sure about the answer to the second part of your question, but I'm
about 99.99% sure you can still use it (anyone else verify?)
Frank
From: Kunal H. Parikh [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
Subject: RE: Single ActionForm accross multiple Actions
Date: Wed, 9 Jun 2004 10:34:27 +1000
Great .. thanks for all the responses...
I think I will go with the ActionForm stored in session-scope.
Just wanting to confirm, that I will need to perform the following code
changes:
==
public ActionForward execute( ActionMapping actionMapping, ActionForm
actionForm, HttpServletRequest httpServletRequest, HttpServletResponse
httpServletResponse ) throws Exception
{
actionForm = httpServletRequest.getSession().getAttribute(myForm);
// ...
// normal code follows!!!
}
==
Also, would I be correct in saying that I will be unable to use the
ValidatorActionForm.
TIA,
Kunal
-Original Message-
From: Frank Zammetti [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 8 June 2004 23:21
To: [EMAIL PROTECTED]
Subject: RE: Single ActionForm accross multiple Actions
This is more or less what a session-scope ActionForm is for. As long as
the
ActionForm class contains all the properties and methods for all the screen
it will service, just putting it in session I think is your best bet. As
someone else said, hidden form fields are your other choice. Actually, you
could also store the data temporarily to a database, but if you would even
consider that, session is really the right answer.
Frank
From: Kunal H. Parikh [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
Subject: Single ActionForm accross multiple Actions
Date: Tue, 8 Jun 2004 12:08:25 +1000
Hi All!
I want to maintain a single ActionForm across multiple Actions.
I want to get the info from the user in a step-by-step manner, but only
wanna talk to the SessionBean at the end when they hit confirm.
The alternative that I can think of is writing a JavaBean with all the
properties, and pass the JavaBean around as a session attribute.
Any one have a better solution ?
TIA,
Kunal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
Watch the online reality show Mixed Messages with a friend and enter to win
a trip to NY
http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/01/
-
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]
_
FREE pop-up blocking with the new MSN Toolbar get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Single ActionForm accross multiple Actions
Hi All! I want to maintain a single ActionForm across multiple Actions. I want to get the info from the user in a step-by-step manner, but only wanna talk to the SessionBean at the end when they hit confirm. The alternative that I can think of is writing a JavaBean with all the properties, and pass the JavaBean around as a session attribute. Any one have a better solution ? TIA, Kunal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single ActionForm accross multiple Actions
Kunal,
You could add a 'state' property to the form, that the first action can
set to 'STARTED' and the last action can set to 'FINISHED' or something
like that, then in your reset() method you could do something like:
reset()
{
if(state == Constants.FINISHED)
{
// reset all vars
}
}
and you could stick the form in the session scope. I think some of the
more weathered Struts people here might have a better suggestion though.
Kunal H. Parikh wrote:
Hi All!
I want to maintain a single ActionForm across multiple Actions.
I want to get the info from the user in a step-by-step manner, but only
wanna talk to the SessionBean at the end when they hit confirm.
The alternative that I can think of is writing a JavaBean with all the
properties, and pass the JavaBean around as a session attribute.
Any one have a better solution ?
TIA,
Kunal
-
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]
