struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <>
Subject Re: How to protect an action from the "user"
Date Wed, 30 Mar 2005 22:53:05 GMT
Hi Leon,

I would first say that you probably want to think about refactoring your 
design.  Actions are designed to be a per-request handling mechanism, so 
anything that is creating persistent objects, or as a result of the 
function creates persistent objects (like a ThreadPool as you 
mentioned), isn't really appropriate in an Action.

The idea of instantiating an Action in another and calling methods on 
it, even if calling execute() itself, is not inherently a bad thing.  In 
fact, it's one fairly elegant solution to the "setup Actions" problem 
(i.e., you do an Action and then need to do some setup for the next 
screen... do you forward to an Action that just does screen setup?  This 
is a good place to think about instantiating that "setup" Action and 
calling execute() on it yourself).  The fact that this causes problems 
in your particular case indicates you may not have a good separation of 

I suppose there are some vaguely hackey ways you could stop the Action 
from being instantiated by anything other than Struts, but I would 
frankly look at solving this from a design perspective instead.

Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies

Leon Rosenberg wrote:
> Hi,
> I have following problem. Recently in code review we found some places,
> where one very young and very inexperienced developer was directly
> instantiating an action:
> in execute of ActionA:
> ...
> ActionB b  = new ActionB();
> b.callSomeMethod();
> ...
> Unfortunately ActionB was getting some resources in constructor (creating a
> JacORB stub) so any call to ActionA resulted in actually creating a
> ThreadPool on both client and 
> server side, as well, as creating a tcp-ip connection between two machines. 
> Since we were always relying on the existence of exactly one instance of an
> Action, creating references to these kind resources from the constructor
> seemed to be ok. Now we moved 
> the new Stub() call from the constructor of the Action in the static{}
> block, which solved the problem for this particular action.
> The question is now, how can I ensure, that an action is actually created
> once, and from proper "caller" without changing 500 existing action classes.
> The only thing I could imagine, would be introducing a test mode, and if
> running in test mode, throw an exception in the BaseAction (mother of all
> actions) constructor, parsing the stackTrace, whether the struts request
> processor was the caller of the constructor and deny the creation otherwise.
> Not very elegant, isn't it? 
> Any other (and hopefully better) suggestions?
> regards
> Leon

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message