struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <>
Subject Re: Some comments & questions on Struts 1.3 chain & Strecks
Date Thu, 08 Jun 2006 20:20:27 GMT
>I have a couple of questions/thoughts/observations that have arisen:
>- the chain configuration appears to apply across the application as 
>a whole rather than per module. This differs from the 1.2 request 
>processor which can be varied/subclassed on a per module basis. (Of 
>course, you can still subclass RequestProcessor on a per-module 
>basis, but the whole point of the chain is that you should not need 
>to do that)

well, I think we have found that very few active Struts developers 
use modules, so some module-centric things get overlooked, 

That said, the per-application config is the loading of the catalog 
factory.  It *is* possible to change which command is looked up in 
the catalogs and executed to process the request as part of the 
controller-config on  per-module basis.

>- the chain seems to be quite good at allowing you to vary the 
>request processing flow. It is more difficult to apply configuration 
>or make services accessible to groups of commands in the chain. One 
>way I can see to do this is by subclassing 
>ComposableRequestProcessor (not that old chestnut again), overriding 
>init(ActionServlet,ModuleConfig), then adding the relevant services 
>to the chain context, using getApplicationScope().put(...). Another 
>way, apparently, would be to load the configuration in the 
>constructor or synchronized block of one of the chain commands, then 
>getApplicationScope().put(). It would be nice if you could configure 
>chain commands using some form of dependency injection, a la Spring, 
>and allow these services to be added via the chain config file. (I 
>suppose I should be addressing this to the chain developers mailing 
>list, although I suspect that most of the chain developers are on 
>this list as well).

(yes, I think this is effectively the chain developers list :) )

Don't forget that you can configure basic properties on any command 
simply by setting xml attributes and letting digester and beanutils 
handle the population.  This is limited to values, not references, 
and is limited by all the limitations for type conversion that 
BeanUtils has, but it can still get you pretty far.

It's not so elegant, but for anything beyond that, I'd probably just 
have command properties whose values were spring bean names, and then 
have the command retrieve the Spring ApplicationContext from the 
ServletContext, and look up a bean from there.

Of course, it's possible to create commands and chains in a spring 
beans XML file too; it's a bit awkward in terms of syntax, but it can 
be done.  Technically, you could create an entire alternative 
CatalogFactory in Spring (or as many as you like) -- there's just no 
good way to inject a CatalogFactory instance into a 
ComposableRequestProcessor instance, because of the way that Struts 
initialization happens.  You could have a 
SpringAwareComposableRequestProcessor which found the Spring 
ApplicationContext during the init(...) method and looked up its 
CatalogFactory there.

I think that in general, the Struts 1.x initialization process is 
awfully constraining, but I haven't had any substantially better 
ideas about how to do it.


Joe Germuska *    

"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed.  Try something new."
	-- Robert Moog

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

View raw message