When you configure your XWork application (be-it WebWork or something else), you define your Action, Interceptors which intercept Action invocation, and Results, which get executed when an Action returns. You have complete control over the implementation of these classes – beyond the fact that you need to implement some basic interfaces (@Action@, @Interceptor@ and @Result@ respectively), however you have absolutely no control over how these classes get instantiated by XWork at runtime – internally XWork just gets your class, and calls @newInstance@. The limit of control you have over how Xwork sets these objects up is in the form of String/Value pairs defined in the configuration.
So why is this a problem? Well, lets take the example of my “Swing/XWork prototype(A GUI framework using XWork)”:http://www.magpiebrain.com/archives/000181.html I posted earlier. In it I created an Interceptor to monitor the progress of an Action. As the Action is invoked and completed, my Interceptor calls methods on a @ProgressRegister@ object. The problem is that I cannot pass references to my @ProgressRegister@ object into the interceptor when created – I am forced into creating a Singleton method accessor on @ProgressRegister@. In an ideal world, I would be able to define my @ProgressRegister@ object, and tell XWork that this object instance should be passed in whenever my interceptor is created:
This is of course exactly how IoC frameworks like Spring and Pico container work (the @bean@ definition from above is actually lifted straight from a Spring XML file). Ideally, XWork’s configuration could be overhauled to use Spring internally, but this is a big job. Instead I have a compromise.
Lets imagine an Interceptor class called @SpringInteceptorFactory@ which implements @Interceptor@. It takes a single string parameter which equates to the name of another Interceptor defined in a Spring config file. When invoked by XWork, @SpringInteceptorFactory@ creates an Interceptor of the relevant type (with properly wired dependencies) and executes it accordingly. This same solution could be used to create @Result@ or @Action@ objects. I can’t escape the feeling that adding yet another config file (in the shape of a Spring XML definition) is going to complicate things, however if you were already going to use Spring (Or Pico/NanoContainer) perhaps its not that much hassle after all.