I'm generally believing that the original motivation for Struts to work this way (pool actions instead of creating one per request) has proven not to be all that useful, and some of the benefits of being able to treat an Action as a request-scoped instance are part of what people like about frameworks like Webwork. It might be worth investigating whether there actually are meaningful performance implications to instantiating an Action upon every request, although a bug in the Struts Chain code (fixed only a month or two ago) was causing this very situation, and it didn't have a noticeable impact on a production application I had built upon it.
Don Brown's Struts-Spring project had a proxy action which created a new Action instance for each request based on a Spring configuration. The project is discontinued in favor of equivalent behavior in the Spring core, but you can get the details on that (and a link to currently active substitutes) at
http://struts.sourceforge.net/struts-spring/index.html
Joe
At 8:02 AM +0000 1/24/05, Fredrik Jonson wrote:
On 2005-01-24, Larry Meadors <[EMAIL PROTECTED]> wrote:
Maybe we are approaching this from the wrong direction. what is the problem you are trying to solve?
Perhaps I am. I have an action which retrieves a couple of values from a database. If the retreival fails, it return some reasonable default values instead. It is these defaults which I want to be user configurable, that is, configurable from some initialization file.
The introspection/set-parameter feature, found in PlugIns, would solve my problem, but it isn't available for actions, only actionmappings.
On Sun, 23 Jan 2005 17:09:45 -0600, Eddie Bush <[EMAIL PROTECTED]> wrote:
Actions are, effectively, singletons. [...] This means actions have to be thread-safe, and suggests that the best place to configure things would be in the mapping itself, or some other way (resource bundle, propeties file, singleton, factory).
The action is specialized, it is only responsible for making sure the values are set in the request's session, so it will not be called from different actionmappings. Further, as soon as the action have been instantiated the configurable member variables will be used as read-only values. So there is no concurrency issue involved.
-- Fredrik Jonson
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
