Following is some of the experiences learnt from using Spring with
Webwork1 (http://www.opensymphony.com/webwork).
I know many developers are trying out Webwork2 and XWork (http://wiki.opensymphony.com/space/WebWork2),
and it's generally agreed that Webwork2/XWork combo can make a much more clean
decoupling between XWorkActions, validators, and interceptors; but given its
ease of configuration and learning curve, Webwork1 should still have its value.
-cptechno
For Webwork, the ServletContext
can be retrieved via ServletActionContext.getServletContext ();
in code it will be
|
|
For simplicity it may be a good idea to make a base class that extends
webwork.actions.ActionSupport, and make a
method that will return ApplicationContext, like this:
|
|
then any Actions can extend this base class and use getApplicationContext() directly.
ApplicationContext can not only be
configured via org.springframework.web.context.ContextLoaderListener, but also from org.springframework.context.support.ClassPathXmlApplicationContext, and org.springframework.context.support.FileSystemXmlApplicationContext as well. In this way, if Webwork
actions can have a way to give them the ApplicationContext, Webwork actions,
together with the JavaBeans configured into Spring, can also perform unit tests
with JUnit easily.
Here is one of the way - give actions a way for others to inject the
ApplicationContext to it.
|
|
The getApplicationContext() method used above can make
modification so that ApplicationContext will be found from ServletContext, if
it is not set externally.
|
|
So in the unit test code the action can be given the ApplicationContext via
|
|
usually you'll do this at setUp() method. And you can check whether the command execution
is successful with something like
|
|
The above methods may not be the best one.
org.springframework.jdbc.datasource.DriverManagerDataSource; EJB? Ooops....