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

[Cameron Braid]

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