struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <>
Subject Re: Thread-unsafe Command classes
Date Mon, 26 Sep 2005 16:11:32 GMT
On 9/23/05, Joe Germuska <> wrote:
> I've recently been designing applications so that per-action-path
> commands are retrieved from Spring rather than from the default
> commons-chain CatalogFactory.  This then makes the lifecycle of the
> command an external property (based on the "singleton" attribute of a
> <bean> element in a Spring beans XML file.)

We've been using a C# port of Commons Chain that uses Spring to load
the Catalog and run the Chains, instead of the Digester. Works great!

We're also using Spring.Web to load other objects. By using Spring to
load Commands, we end up with a single set of configuration files that
exposes all the objects we using under one XML schema. The exception
right now is iBATIS.NET. But, I don't see why we couldn't load that
object graph with Spring.Net too, so that we have one configuration to
rule them all.

> Of course this required custom request processing commands, since
> Struts 1.3 doesn't have direct dependencies upon Spring.

I keep thinking that we should be able to make object-graph loading
pluggable, like Shale is starting to do with Spring versus the JSF
bean manager. This is something we could look at in the Struts Core
1.5 series, when we plan to "Consider refactoring for Spring."


Here, where we say "Spring", I read it to say "dependency injection",
since if we do this, I think we can do it through pluggable interfaces
so that there is not a hydraulic dependency on Spring per se.

> The best thing I think would be to write a command which instantiated
> this other arbitrary class, extracting properties from the Context to
> pass to the "main" method of the arbitrary class and interpreting the
> return appropriately (possibly modifying the Context as well.)


On 9/24/05, Joe Germuska <> wrote:
>Those are concerns for  commons-chain.


> What we should do in the Struts core is make sure that things are
> properly designed for easy extensibility.


Personally, I also believe that we should try harder to encourage
people to move as much application logic as possible out of Struts and
into a separate business or application layer.

The point of using Commons Chain as the basis for Struts Core is *not*
to make it easier for us to put more business logic into
Struts-centric Actions or Commands. (And I'm *not* implying that
anyone in this thread is encouraging that practice.)

The point of using Commons Chain is to make the Struts Core easier to
extend and customize so that we can do less work in Actions. As a
framework, an important goal should be to make it easier for us to
draw a firm line between Struts and the rest of our applications.

Just as Struts Core uses Commons Chain to create it's own internal
application layer, we encourage other teams to use Commons Chain -- or
XWork, or POJOs -- to create their own internal application layer --
clearly separate and distinct from Struts. We should not be writing
applications with Struts Core, we should be writing application *into*
Struts Core, so that it's easier to write them into something else as
well. (Like say, a unit testing suite!)

Which I think is my queue to put some volunteer time into improving
MailReader :)

-- HTH, Ted.

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

View raw message