On 9/23/05, Joe Germuska <[EMAIL PROTECTED]> 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 th
The point I was trying to make is that using "command" and "catalog"
to look up a per-action-path command to execute should leave Struts
out of any concern for the lifecycle of the Command classes; the
implication of those attributes is that the command will be looked up
from a CatalogFactory,
> -Original Message-
> From: Wolfgang Gehner [mailto:[EMAIL PROTECTED]
> Sent: 24 September 2005 11:06
> To: Struts Developers List
> Subject: Re: Thread-unsafe Command classes
>
>
> If I want to use Spring I use Spring MVC, but I think a lot
> of drive i
If I want to use Spring I use Spring MVC, but I think a lot of drive in
Struts evolution is to encorporate nice ideas that have come up as
techniques elswhere over the last years, see Struts TI. So Struts
developers won't *have to* use Spring on top or instead. (I am not
convinced that TI shoul
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
element in a Spring beans
