Re: [OS-webwork] [OS-xwork] Spring IoC integration

[Cameron Braid]

I have downloaded and integrated this code though and the tests run perfectly (after creating my my own ServletContextAware interface and removing refrences to the confluence packages) I really like the work that you have done. Though I think some more work is required to be able to integrate into xwork/webwork I can't see how the servlet context is set onto the SpringServletContextReferenceResolver or the ApplicationContext is set onto the SpringApplicationContextReferenceResolver (depending on the one that is used) you construct the ExternalReferenceResolver using this code, and immediately add it to the package config.                 Class erResolverClazz = ClassLoaderUtil.loadClass(externalReferenceResolver, ExternalReferenceResolver.class);                 erResolver = (ExternalReferenceResolver) erResolverClazz.newInstance(); I guess that the ServletContextAware interface could be added to webwork, though the question remains - how is the ServletContextAware.setServletContext(..) method going to get called ? I propost the following soloution : 1 : have different SpringXXXReferenceResolver classes in xwork and webwork like this : xwork : SpringClassPathXmlApplicationContextReferenceResolver or a SpringFileSystemXmlApplicationContextReferenceResolver webwork : SpringWebApplicationContextReferenceResolver - using WebApplicationContextUtils.getWebApplicationContext(ServletActionContext.getServletContext()) to obtain the application context This works find for webwork based apps, though for xwork based apps that the SpringClassPathXmlApplicationContextReferenceResolver and SpringFileSystemXmlApplicationContextReferenceResolver require configuration to specify the filename.. therfore step two is required : 2 : allow for external refrence resolvers to be declards by name, class and to be parameterizable like interceptors.  the refer to the by name instead of className e.g. : <xwork>     <package ... externalReferenceResolver="spring">        ....     <!-- NEW FEATURE : new node set -->         <externalRefrenceResolvers>            <externalRefrenceResolver name='spring' class="SpringWebApplicationContextReferenceResolver"/>            <externalRefrenceResolver name='springXmlFile' class="SpringClassPathXmlApplicationContextReferenceResolver">               <param name="filename">myApplicationContext.xml</param>             </externalRefrenceResolver >         </externalRefrenceResolvers>        ....        <action name='...' class='...'>         <!-- NEW FEATURE : externalRefrenceResolver attribute -->           <external-ref externalRefrenceResolver='springXmlFile' name='foo'>myFoo</external-ref>           <external-ref name='bar'>myBar</external-ref>        </action>     </package> </xwork> this allows for reusing the same configured  resolver in multiple packages - which you can do now, though without configuration. this allows for each external-ref tag to optionally use a different resolver as in the example above I am sure that other frameworks will require some sort of runtime configuration  for the external reference resolvers as well. Any comments ? Cameron Ross Mason wrote: Cheers mate. I've just attached the SpringExternalReferenceResolver implmentation and tests to the Jira Issue. http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-122 Ross Patrick Lightbody wrote: This is good stuff -- not sure about a 1.0 release though. We'll try to get a point release out shortly after though to support this. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ross Mason Sent: Monday, November 17, 2003 8:02 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] [OS-xwork] Spring IoC integration I'll fix the commons dependancies first :-) Ross Mason wrote: I've tried running the patch again (through Eclipse) and I get the same problem - It only creates patch entries for new files?  I know this isn't a subject for this list, but does anyone know why this happens? Anyway Cameron,  I'll create a zip of the changes for now and attach it to the the issue and this list. Cheers, Ross Cameron Braid wrote: The patch seems to be missing code in the configuration classes... since I have applied it, I am geting compilation errors : not defined : invocation.getProxy().getConfig().getPackageName() invocation.getProxy().getConfig().getExternalRefs(); packageConfig.getExternalRefResolver() Thanks, Cameron Ross Mason wrote: Hi, As per the discussion late last week, we have a patch for Xwork so that it can use an external container to resolve component references. I've created the following issue - http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-122 I've added a breakdown of the changes below, in summary, this is how it works- You can configure a action to have external references in the xwork.xml using a new <external-ref> tag on the action When the action is configured the external refs are stored on the action config. When the action is invoked, there is a new interceptor that will resolve these references.  It does this by using a new attribute on the package config called externalReferenceResolver i.e. <package name="default" externalReferenceResolver="com.atlassian.xwork.ext.SpringServletContextR eferenceResolver"> In this case, the SpringServletContextReferenceResolver implementation will handle the work of looking up and setting the references on the action. Note, if a resolver is not found on the actions package, it will tranverse up the package heirarchy to find one. We have an implementation for Spring, but I have not included it in this patch as it should probably go into an xwork-ext sub-project.  Let me know what you want me to do with this... Here are the changes and additions to the xwork codebase - 1. added 2 new config attributes - - a new element external-ref to the action element in the config. i.e <external-ref name="foo">Foo</external-ref> where name is the setter method name and Foo is the reference to lookup. - added an attribute to the package element called externalReferenceResolver which supplies a FQ classname to an ExternalReferenceResolver implementation. 2. Updated the xwork DTD accordingly. 3. Added 4 new classes - - External Reference - an encapsulation of the external-ref tag - ExternalReferenceResolver - an interface to provide implementations for resolving references from an external container - ExternalReferencesInterceptor - will resolve references on a given ActionInvocation - ReferenceResolverException - thrown by ExternalReferenceResolver 4. Added support for external references to the ActionConfig. I also added the attribute packageName to the ActionConfig, so that the Interceptor could determine which package the action belonged to in order to find the externalReferenceResolver. 5. Added support for the externalReferenceResolver attribute to the PackageConfig. 6. Added support for the extra configuration to the XMLConfigurationProvider and DefaultConfigurationProvider 7. Added tests in the org.opensymphony.xwork.config.ExternalReferenceResolverTest I've attached a cvs patch with all the changes.  I built the patch against the latest src. Cheers, Ross ------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ 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: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork