|
Sort Order:
Fixed code to reflect new heirarchy of the XmlWebApplicationContext (extends from AbstractRefreshableApplicationContext instead of just AbstractXmlApplicationContext). I like this idea! In addition to removing the double-configuration of Struts actions, this should cut down the startup time of my app by quite a bit, since it will only need to instantiate 1 ForwardAction instead of 100. Thanks for this contribution, I was thinking about implementing something like this myself before. Works like a charm, please consider including this in Spring1.2 I used this approach as well once but instead I created a common base class that did the autowiring for me. About this solution: the current impl. is inheriting from DelegatingRequestProcessor. Shouldn't it just extend the normal RequestProcessor? The delegating RP looks up a Spring bean in the application context, which is not what you need, is it? I think the best approach would be to configure your actions in Struts and when they are processed by the RP, autowire them. This means you don't have to configure them in Spring anymore. Also, is the autowire by name the default you wan't to use? Please advise... In the implementation provided I was trying to be flexible. I extend from the DelegatingRequestProcessor to handle situations when you want more control over the wiring. So the impl lets the superclass attempt to find the bean in the container first...if found it uses it. If not found, it will instantiate and autowire it by name. I thought it was kind of a best of both worlds: autowire by name for most actions...then for actions that need more care, wire them directly. Honestly in the projects I've used it on, we never had a need to directly wire the action...but it was just TOO easy to allow the flexibility. I did autowire by name because that is what fit best with the projects I needed it for. There were times when we had multiple implementations of a service interface that needed to be autowired, in these cases autowire by name suited best. The naming convention was already such that it required no code changes. I'm happy to see some movement on this. Its been a really handy piece of code for me. +1 for autoWireByName as default, this is IMHO the best fit for most situations. How about a configuration option for autoWireType, so it can be reconfigured to e.g. autoWireByType via the struts-config.xml? I've finally added an AutowiringRequestProcessor and corresponding AutowiringTilesRequestProcessor. Those essentially delegate straight to the ApplicationContext's AutowireCapableBeanFactory to autowire the bean properties of every created Action instance. The default autowire mode is by type, since we do use this as a default in other places as well. However, I do see the point that autowiring by name is often preferable (and I generally agree with that). The autowire mode can be switched through the "spring.autowire" init-param of the Struts ActionServlet (for example with value "byName"). Accordingly, dependency checking can be activated through the "spring.dependencyCheck" init-param (for example with value "true"). Juergen |
|||||||||||||||||||||||||||||||||||||||||
New Feature
Resolved
Minor
Autowiring Struts Request Processor
Source for the 2 Request Processors.