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 responsibilities.
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 http://www.omnytex.com
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
