struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Zoio <>
Subject Re: Some comments & questions on Struts 1.3 chain & Strecks
Date Fri, 09 Jun 2006 21:34:01 GMT
Joe - Thanks for the detailed reply. While supporting Spring integration 
is very important with Strecks, I took the decision to avoid using 
Spring to configure the framework extensions - I've wanted to limit 
dependencies to those already present in Struts.


Joe Germuska wrote:

>> 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, unfortunately.
> 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 use
>> 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

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

View raw message