Comments on: XWork: Actions, Interceptors, Results and IoC

By: Sam Newman

Sam Newman — Tue, 24 Feb 2004 16:10:50 +0000

Using Spring for some of the XWork internals would still give you a command pattern decoupled from direct method calls – in fact it would be possible to configure yourself which method got called on an Action to execute it for example, giving an even more abstract framework (the need for interfaces vanishes).
Certainly XWork has value – it is a framework with a specific task that works well at what it does. Sure, someone could implement something similar using Spring on its own, but they would still have to supply the higher level mappings to make it as easy to use as XWork. I still think that by using Spring internally, you would be left with a system with the same API as now, but with more flexibility. Spring can handle Action and Result invocation, and handle interceptors, and to get the full benifit out of integrating with Spring this would make sense. The question is, is this added flexibility worth coupling XWork to another framework (be it Spring or Pico or…), or is it worth the reimplementation work.

By: Jason Carreira

Jason Carreira — Tue, 24 Feb 2004 15:36:30 +0000

I’m not sure that’s true… there’s value in a command pattern implementation that’s decoupled from direct method calls… Plus, XWork Interceptors give you access to XWork specific internals like the ActionInvocation.

Results, etc, are more things XWork would add… Don’t let AOP blind you to the power of normal OOP ways of doing things.

By: Sam Newman

Sam Newman — Tue, 24 Feb 2004 11:08:42 +0000

I think that is what XWork would become if you integrated it with Spring. Much of XWork’s internals would vanish to be replaced by Spring. I’m actually starting to think that in such a situation there is very little XWork left…

By: Juan Murillo

Juan Murillo — Mon, 23 Feb 2004 23:47:50 +0000

This of course also begs the question of whether a command pattern implementation on top of Spring would be an interesting addition to that framework, considering it already has AOP for interceptors and lightweight container for contexts.

By: Jason Carreira

Jason Carreira — Mon, 23 Feb 2004 16:36:54 +0000

You could also populate the ActionContext ThreadLocal with the relevant objects your Interceptors can use. Your calling object could be set up using Spring to have the objects it needs, then put them in the extra context map that you pass to the ActionProxyFactory, and they will be available to your Interceptor via ActionContext.getContext().get(KEY);

I do want to make it easier to make these other objects be built by outside containers, but it’s going to have to wait till at least 1.1….