Now, my problem is in coming up with a way to unit test some ww2/xwork actions. ww1 had a TestDispatcher, this email is a suggestion to refactor, creating a base Dispatcher class in xwork. This would be extended in ww2, and the current different ww2 dispatchers (filter, servlet) would delegate to that dispatcher. At the same time, a junit test case could easily create and then delegate to a dispatcher to setup and invoke actions. The xwork Dispatcher provides a common set of functionality shared by the web and non-web applications. Please feel free to correct or flame where appropriate.
The ComponentManager and ComponentConfiguration are created and passed as a parameters to the Dispatcher's constructor. The Dispatcher fetches the ConfigurationManager which via the XmlConfigurationProvider loads the xwork.xml. The Dispatcher handles constructing the ActionContext and invoking actions. The Dispatcher adds xwork level contexts such as the value stack, the ComponentManager and the Dispatcher itself (ServletDispatcher currently does this).
Derived classes could override protected methods such as createContextMap() calling the base class implementation and then adding to the map. For instance, a ww2 WebDispatcher would add servletConfig and the servletContext (application). An instance of the WebDispatcher would exist in the ServletDispatcher which would delegate to that class. The ServletDispatcher works the same way it does now, in that it retrieves the ComponentManager and ComponentConfiguration from the ServletContext where it was placed by the ApplicationLifecycleListener.
The Dispatcher would have a method for invoking the action that would take similar parameters that the DefaultActionProxy takes (which it would be creating). WebDispatcher could add a method such as webInvoke() that would add some new parameters such as request and response which would cause the request attributes, parameters, etc, as well as the response to be added to the extraContext Map. This would then be passed as the parameter in a call to the base Dispatcher's invoke() method.
Now WebDispatcher (or any other Dispatcher) could be used in a junit test case and a specific action invoked. A framework such as MockObjects would provide mock javax.servlet.* classes for the WebDispatcher (yes, some such as the MockHttpServletRequest need to have their attribute handling overridden). It may seem like a lot of refactoring, but it is mostly moving some functionality down to xwork and providing a shared base class. What do you think?
This also provides enough functionality at the xwork level that it becomes trivial to create powerful custom servers. Just add util.concurrent. For each "application", create a channel object, which creates the ComponentManager and ComponentConfiguration, and spawns a number of consumer worker threads. Each thread constructs a Dispatcher with references to the ComponentManager and ComponentConfiguration. Each thread has a valid ActionContext. It then pulls requests from the queue and dispatches them. This could be used for anything from driving a number of letter writing printers, to a massively parallel system using MPI (message passing interface).
Fred
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
