I have mentioned the reasons for parameterization in a previous post.
The configuration I speak about could be information to inform xwork how to handle reloading of resolvers when the configuration changes, as well as any other lifecycle configuration that may be required for the resolver.
Something like :
<xwork>
<package ...>
<external-resolvers>
<external-resolver name="springWebAppContext" class="com.xwork....SpringWebApplicationContextExternalResolver" reCreateOnReload="false">
<!-- insert any parameters here, that are set onto the instance of the class -->
</external-resolver>
<external-resolver name="springSecurity" class="com.xwork....SpringFilesystemContextExternalResolver" reCreateOnReload="false">
<!-- insert any parameters here, that are set onto the instance of the class -->
<param name="filename">securityContext</param>
</external-resolver>
</external-resolvers>
</package> </xwork>
I would also implement SpringWebApplicationContextExternalResolver so that it retrieves the ServletContext from ServletActionContext.getServletContext() when it needs it.
Cameron.
Chris Chen wrote:
I checked out the code to use to integrate xwork/webwork with spring. I was utilizing the interceptor classes posted to the JIRA.
But I ran into an issue. It's not entirely a critical one, but just thought perhaps people should know.
The issue is that when you set the property to have webwork do xml reloading, it will reload all the external-ref resolver classes as well and instantiate new ones.
How does this affect the spring integration or the spring resolver? Well, the application/servlet context set in the spring resolver is done in the context listener when the web-app is first initialized. Thus, when xwork reloads the xml config, the context listener is not notified to set the servlet context again for the spring resolver, resulting in a null application context inside the resolver and thus throwing an exception for the resolver.
The workaround is obviously to just disable the xml reloading for xwork.
However, I am wondering if there is a better way to set the servlet context for the spring resolver than to use a context listener? Maybe have the servlet context be retrieved through WebApplicationContext.getServletContext() in the spring resolver rather than go through the context listener?
Or perhaps there's a better way.
Thanks, Chris
------------------------------------------------------- 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
-- Any damn fool can write code that a computer can understand... The trick is to write code that humans can understand. [Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]
------------------------------------------------------- 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
