Francois, :)
As for why it's required, it makes everything more flexible - and it's not required at all. Just ignore it and it will do you no harm. Pico is good (for somethings) but personally I much prefer Spring (that's a large debate for another time - each to their own) :) - XWorks IoC container requires interfaces on your actions. - Pico requires a custom constructor and your own factories. - Spring requires external references (in one way) You can also use Spring exactly like Pico if you want (using constructors), but I actually like the explicitly defined contracts that the external references give you. Basically treat an external reference as a chance for some code to resolve references on the action (IoC is just one use for them) at a user defined time (you can't do this with Pico - it's a constructor, it's done when the object is constructed). With the ExternalReferenceInterceptor it's a part of the interceptor chain, so I can govern when those references are resolved (before Params? After Params? After Validation?) I have control. Anyway - some thoughts - don't get fooled by the Pico folk, it's not the be-all-and-end-all of IoC - it's just one solution. :) M On 12/12/03 6:15 PM, "Francois Beauregard" ([EMAIL PROTECTED]) penned the words: > Why all of this external reference resolver thing gets into XWork? > > Couldn't you just extend DefaultActionProxyFactory, DefaultActionInvocation > and do whatever logic to integrate with the IoC container and/or use an > interceptor? > > Even XWorks own IoC container does not need this kind of modification to > XWork.xml, it looks like it only needs an interceptor and stores its > configuration in an xml file. > > You can also have a look at PicoContainer's integration (in NanoContainer), > it is neatly done. > > Cheers, > ___________________________ > François Beauregard, b.ing. > Vice-président > Recherche et développement > Pyxis Technologies > www.pyxis-tech.com > > T : (450) 681-9094, poste 102 > F : (450) 681-5758 > [EMAIL PROTECTED] > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Cameron Braid > Sent: December 12, 2003 1:32 AM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] [OS-xwork] Spring IoC integration > > > 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.get > ServletContext()) >>>>>> 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 > > > > ------------------------------------------------------- > 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
