The modifications that I have made won't be going into Xwork since the
existing functionalty should be sufficient for most (probably all)
needs.
The existing system allows you to define an external refrence resolver
(per package, with inheritence from the parent package).
You can then add <external-ref> tags to the actions to explicitly
define the component names to use.
There is an implementation of SpringExternalRefrenceResolver attached
to a JIRA task somewhere at http://jira.opensymphony.com though there
are still some issues with reloading the xwork configuration. I am
implementing a fix for this so that it won't matter if the xwork
configuration is reloaded.
I am also working on an alternative binding system that uses Spring's
autowire system that can autowire by type and/or name (similiar to
pico/nano) I have found problems with this . If your spring
application context contains a bean that is a Map, the autowire gets
this bean and sets it onto ActionSupport.setFieldErrors(Map), or even a
more basic one - any string. I think autowiring is a little trickier
than people think. This is probably more complex within spring because
the application context can store any type of object.
I have a soloution as a temporary basis. All the beans in spring that
I need to access from actions are my service layer beans, which all
implement a superinterface "Service".
I only autowire the action properties that are of this type.
Cameron.
Rob Rudin wrote:
Cameron - how is this integration working out? We're on Webwork
1.3 at work, and I've got it tied into Spring to load Actions by
using an ActionFactoryProxy. I was reading the Java Open Source
Programming book, and it got me interested in upgrading to
Webwork2, but I really don't have a lot of interest in using
XWork's IOC container, and I'm concerned about how well the
integration will work between Webwork2 and Spring based on some
posts I've seen.
Rob
---- forwarded message attached ---
It looks like noone else is interested in discussing this.
I have refactored xwork so that the external refrence resolvers are
defined as described below
<xwork>
<package name='test' extends='webwork-default'>
<external-resolvers>
<external-resolver name="test"
class="com.opensymphony.xwork.config.TestExternalReferenceResolver">
<param
name='stringParam'>stringParamValue</param>
</external-resolver>
<external-resolver name="test2"
class="com.opensymphony.xwork.config.Test2ExternalReferenceResolver"/>
</external-resolvers>
<default-external-resolver-ref name='test'/>
<action name="TestExternalRefResolver3"
class="com.opensymphony.xwork.ExternalReferenceAction">
<external-ref required="true"
name="Boo">myBoo</external-ref>
<interceptor-ref name="debugStack"/>
<interceptor-ref name="defaultStack"/>
</action>
<!-- test where external-resolver-ref overrides the package's
resolver -->
<action name="TestExternalRefResolver5"
class="com.opensymphony.xwork.ExternalReferenceAction">
<external-ref name="foo"
external-resolver-ref='test2'>myFoo</external-ref>
<interceptor-ref name="debugStack"/>
<interceptor-ref name="defaultStack"/>
</action>
</package>
</xwork>
I have updated the test cases to use this new structure, and added
tests for the new features.
This has required that the ExternalReferenceResolver interface be
changed a little bit, simplifying the implementation.
Previousally ExternalReferenceResolver.resolveReferences(..) had to
resolve all external refrences for an action, where as now it just
resolves a single refrence at a time.
public interface ExternalReferenceResolver { public void
resolveReferences(ActionInvocation invocation, ExternalReference
reference) throws ReferenceResolverException;
}
This simplifies the implemetation of the resolver because it doesn't
need to know about the ActionConfig at all, since ExternalReference
contains the action property name, the external ref string and the
required boolean.
It is the responsiblity of the ExternalReferencesInterceptor to call
the relevant resolver for each <external-ref> tag for the action.
I can add a Jira task, and attach the patch if anyone is interested.
I would prefer that this code gets added before the final release.
Cameron.
Cameron Braid wrote:
Ross Mason wrote:
Cameron Braid wrote:
Ross Mason wrote:
Cameron Braid wrote:
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
Cool!
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 ?
We could use a ServletContextListener to set the contexts on our
resolvers... Could we access the packageConfig from a listener?
Yeah I guess we could, though this starts to get ugly when each
different resolver needs its own listener that is bound to the action
config api.
You only need one listener to set the Servlet context on all Resolvers
that are ServletContextAware. I'll attach the one I'm using to the
issue.
Sounds like we need to get the DefaultComponentManager to bootstrap the
external refrence resolvers ;)
Actually... my point here was that each type of resolver... ie the
spring one, the XXXFramework one and any other framework integration
one will require someone to code a specific ConfigurerListener to set
any external resources that the resolver requires. I think that if this
can be done with simple parameter based configuration then it will be a
lot simpler.
I propost the following soloution :
1 : have different SpringXXXReferenceResolver classes in xwork and
webwork like this :
xwork : Spring/ClassPathXmlApplicationContext/ReferenceResolver or a
Spring/FileSystemXmlApplicationContext/ReferenceResolver
webwork : Spring/WebApplicationContext/ReferenceResolver - using
WebApplicationContextUtils.getWebApplicationContext(ServletActionContext.getServletContext())
to obtain the application context
I agree, we should have different implementations, separated like
this. In my test case I have provided a
Spring/XmlFileApplicationContext, so we could just refactor that out.
Certainly can.
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
Ok that looks like it would work, I think we should declare resolvers
the way you suggested. Though I don't think we need then
externalReferenceResolver attrib on the external-ref element. We can
just assume all actions in a package use the same Resolver. I think
it's neater that way; You can still use different Containers on
different packages to resolve your references and there would be a more
logical grouping of package/container.
I agree that is is not necessary to allow the resolver to be overriden
per external-ref though I think it could be a usefull feature to have.
Say you are using a thirs party spring based component package - say
for security - and you want each action's securityManager property to
be resolved from this context instead of the package's one.
I guess that another way of specifying it would be to use
<external-ref
name='foo'>springXmlFile:myFoo</external-ref>
and to modify the interceptor to look for the : char.
just my 2c worth ;)
See your point, I guess we need to throw the notation up for
discussion.
I don't really mind the syntax for specifying which resolver to use.
SO there are two questions
1. Do we need to be able to override the resolver on a per refrence
basis
2. If we can override, what is the syntax ?
Does anyone else have any thoughs or suggestions ?
I am sure that other frameworks will
require some sort of runtime configuration for the external reference
resolvers as well.
Any comments ?
yep!
Cameron
Cheers,
ross
Thanks
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
-------------------------------------------------------
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
--
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
|