cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: AbstractAction Poolable?
Date Thu, 11 Apr 2002 12:43:53 GMT
Ivelin Ivanov wrote:
> Not being an Avalon specialist, I think that Nick has a good point.
> Why shouldn't the AbstractAction be poolable?
> It's been an inconvenience that Strut's Actions must be thread safe.
> Actions usually deal with forms and tend to hold on to a bunch of stateful
> objects. (validatiors, a list of timezones, a list of countries, user
> locale, session, request, etc.)
> It feels cleaner when you don't need to pass these objects around during an
> Action execution.
> Of course you can use ThreadLocal and get away, but it'll make UI coders'
> lifes easier if they don't need to think threads. Memory is not as expensive
> as it used to be ...
> Please correct me if my point makes little sence.
> Ivelin

Ivelin, you missed the point of the response.  Cocoon actions are not
required to be ThreadSafe (they *used* to be, but not now).  When
someone introduced dynamically generated Actions (can't remember who)
we decided that it was proper to use the same decision process for all

Choosing whether a component is ThreadSafe, Poolable, or requiring the
Factory method is an **implementation** detail.  It is an error to
implement multiple lifestyle methods, and the ECM
(ExcaliburComponentManager) will throw an exception.  Make no mistake,
the AbstractAction should not implement *any* lifestyle interface.

When you write your action, the final implementation implements the
correct lifestyle interface.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

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

View raw message