Well, I don't think we're up for doing a ton of refactoring right now, as we're trying to get 2.0 out the door.
For unit testing, you can just directly use ActionProxyFactory to create ActionProxies, which do most of what you're looking for. As far as having multiple dispatchers running at the same time with their own configuration... This is not currently supported. Configuration is static and applies to a whole JVM (which is not usually a problem in a web-centric world, or even most apps) and could be managed with a custom classloader hierarchy. I think it would be a good idea to look at making more of our internal components, like configuration, into actual components and make them managed by a container, but that's probably post 2.1.... > -----Original Message----- > From: Frederick N. Brier [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 02, 2003 8:05 AM > To: [EMAIL PROTECTED] > Subject: [OS-webwork] Unit testing and ActionContext > > > First, let me say I really like Webwork2/XWork. Struts tries > to do the > job of mbeans, security, and other tasks the container > already handles. > Webwork's interceptors, IoC, all in one actions, the ActionContext, > concise set of tags, support for Velocity are all focused on > generating > dynamic content. I don't feel like I am dragging around a lot of > unused, bulky, half implemented functionality. > > 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 > ------------------------------------------------------- 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
