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
components.
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.
Period.
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
