I had a few thoughts on this one that are not directly related to your
question but which impact what you are doing.
A.
What the heck is ActionB b = new ActionB() doing in there? Why not
Action b = new ActionB()?
B.
If you were relying on only one instance of an Action being available,
why didn't you protect against the possibility of more than one
instance?
C.
I think that, even if David's answer helps you, Frank is right that
you really need to rethink this design.
I hope this helps.
Jack
On Thu, 31 Mar 2005 00:23:03 +0200, Leon Rosenberg
<[EMAIL PROTECTED]> 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
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
