I’ve looked over the initial work done to integrate “XWork with Spring(Support for resolving component References in external IoC containers such as Spring)”:http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-122. That proposed solution just used Spring to resolve external components – an @ExternalReferenceResolver@ is used to provide named objects, and a Spring specific implementation is created to access and retrieve objects from Spring itself. Whilst this does solve some of the limitations of the current XWork form of IoC, this feels Ugly – you are taking an incredibly flexible IoC framework and using one little part of it, whilst keeping your own more limited framework. I would like to see the existing XWork API become a wrapper on top of Spring. By all means keep the existing XWork configuration format, but extend it to support Spring-like features. Use Springs Interceptor’s, its invocations – leverage all of Springs excellent existing code. Fair enough, XWork then just becomes a thin wrapper on top of Spring, but you’ll end up with a more flexible command-driven framework, which would in all likelihood find far more use outside of WebWork than is currently the case. Once done, you can then remove the need for @Interceptor@, @Action@ and @Result@ methods – Spring doesn’t need them.
Note that anything I say regarding Spring can equally be applied to another type 2 or 3 IoC container.
-
Follow
Following
Already have a WordPress.com account? Log in now.
magpiebrain 
3 Responses to “Spring + XWork”
I tend to wholeheartedly agree with you. Some parts of Xwork, like interceptors, could be handled by Spring and Xwork actions would benefit from being POJOs, in general it makes good sense.
Whether this happens or not is basically a matter of internal project politics and OpenSymphony goals. But i root for the addition of a command pattern framework on top of Spring, and Xwork seems to be the best one out there.
I just read Jason’s post on the entry before this one and realized that I don’t know Xwork well enough to know whether it would loose by usign Spring as a base.
It would be very cool to have it work that way though 😉
I don’t see how XWork can loose, beyond the fact that it then becomes dependent on Spring itself. At worst the framework maintains is current capabilities – at best it has a more fully featured IoC framework built right in. Much of XWork’s internals would disappear, but there is a lot of value in the command framework itself and this would remain.
I’m going to see if I can come up with a working Spring XWork prototype, to at least gauge the amount of work involved.