struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: why only one instance of Action class (Action class thread sa fety)
Date Wed, 07 May 2003 01:41:34 GMT

On Tue, 6 May 2003 Brendan.Johnston@WellsFargo.COM wrote:

> Date: Tue, 6 May 2003 17:08:50 -0700
> From: Brendan.Johnston@WellsFargo.COM
> Reply-To: Struts Developers List <>
> To:
> Subject: RE: why only one instance of Action class (Action class thread
>     sa  fety)
> The struts designers clearly do not agree that actions
> should be single use.  They are not single use now.

The real key is whether your business logic is embedded in actions or not.
If it is, I would suggest that you are making a mistake.

If you want per-request instantiation of buesiness logic objects (so that
you can use instance variables), the appropriate design is to do that
inside an Action.  Properly designed, these business objects should not
have any linkage to servlet or Struts APIs -- they should be configured
simply by property beans setters or parameters to the constructor.  You
can easily provide per-request instantiation as a service in your Action
as well if you want.

If the single-instance nature of Action gets in your way, that is a pretty
good clue that you aren't factoring your application correctly.

> This shows that Struts designers have different tastes to me.
> I have yet to see one advantage of singleton actions.
> What advantage of singletons am I not getting?

Struts gives you mapping of logical paths to instances of an Action class
where the caller doesn't have to know the name of the Java class, or worry
about instantiating it.  Nothing you couldn't do for yourself with
singletons, but you would need to replicate this logic.

> I have responded to the other comments.
> But this seems like a useless distraction
> if Singleton actions have zero advantages.
> All parts of a web application do not have to be reentrant.
> ActionForms do not have to be reentrant.

Absolutely not true if the form bean is in session scope.

> In general re-entrant code is very hard to test and therefore likely to be
> buggy.
> I would suggest that all part of a web application
> that are written by applications prgrammers should not be re-entrant.

For business logic developers, you can make a good case for this --
indeed, I would go further and say these classes should not depend on
struts apis either.

> To avoid the problem Craig mentioned with session,
> one solution is to insert a standard object whenever you create a new
> session,
> and in your request processor / wib action server / some filter, synchronize
> on that object.  I think I might implement that.

Feel free -- but I wish you'd also look at the benefits of decoupling a
little bit first.  Think of a Struts action as an adapter between the web
tier and the business logic tier, not as a container for business logic.

> All the actions I have written have no instance variables.
> That's because instance variables would be useless/dangerous
> because they are shared by all requests.
> However OO provides instance variables and they are useful in my designs.
> When I look at actions, I see functional decomposition,
> not object oriented designs.

So use 'em ... just not in Actions :-).

> Instantiating another object to get around this sometimes does not
> work well with subclassed actions.
> For an example of a shorter parameter list, see the wiki posted by Ted.
> Based on road map I don't agree/understand why this is a struts 2.0 issue.
> There is no need to break backward compatability.

Changing Action itself would break backwards compatibility for people who,
based on the promise that there is one instance of an Action, do expensive
one-time setup operations when the Action instance is created.

But the right answer to getting what you want in Struts 1.x is to provide
your own Action that implements per-request instantiation of your business
objects.  You don't need the framework to provide that for you.

Note that it's certainly feasible to add this service into a later Struts
1.x release -- but it will NOT be done by making Action into a
per-request-instantiated object.

> Brendan

Craig McClanahan

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

View raw message