RE: [OS-webwork] Re: [Springframework-developer] Re: XWork/Spring integration

[Patrick Lightbody]

I am up for supporting Spring better â just not for beta 2 (or maybe even 2.0, it might have to wait for 2.1). One thing though:   In one of the examples Cameron gave, interceptors were getting params when the ref was declared inside the action. I know weâve talked about doing this, but I donât think weâve ever supported this actually.   -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew E. Porter Sent: Sunday, October 26, 2003 6:08 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Re: [Springframework-developer] Re: XWork/Spring integration   I have no preference. The only disadvantage is the extra XML, but that is a silly reason to justify one over the other. Is there something I am missing? I would like to see this done ASAP and am willing to help. Cheers, matthew On Oct 26, 2003, at 5:24 PM, Cameron Braid wrote: Sorry.. I made a mistake with my example action... It should be : <action name="Bar" class="mypackage.MyAction">      <param name="foo">17</param>      <interceptor-ref name="springContainer">         <param name="mapping">             dataSource=myDataSource         </param>      </interceptor-ref> </action> The "mapping" parameter specifies a list of beanPropertyName=componentName mappings. On Mon, 2003-10-27 at 04:10, Cameron Braid wrote: I am cross posting this message because it is a response to one on the Spring Framework list, and it is more WebWork/Xwork related. I was thinking of doing a similiar thing as outlined below, but instead of introducing a new <external-ref> tag into the xwork.xml config files, I was going to do it with an interceptor. Therefore I would configure the interceptor using <params to tell it which component names map to which action properties. <action name="Bar" class="mypackage.MyAction">      <param name="foo">17</param>      <interceptor-ref name="springContainer">         <param name="dataSource">myDataSource</param>      </interceptor-ref> </action> I do like the idea of supporting an external-ref type syntax, if other people think it is a better idea. Cheers, Cameron On Sun, 2003-10-26 at 04:09, jÃrgen hÃller [werk3AT] wrote: Hi Matthew, I suggest to add the "external-ref" tag to the XWork XML file itself, just like the existing "param" tag. This is basically an inversion of the current XWork component approach -- "pulling" in named component instances instead of "pushing" them to the actions. <action name="Bar" class="mypackage.MyAction"> <param name="foo">17</param> <external-ref name="bar">myDataSource</external-ref> </action> The MyAction class could look as follows. Note that there's no enabler interface involved; the bean property and thus the setter is determined via external-refÂs "name" attribute, just like with the param tag. public class MyAction implements Action { private DataSource dataSource; public void setDataSource(DataSource dataSource) { this.dataSource = dataSource; } ... } As this involves support in the XWork XML file, the XWork action processor will need to implement the external-ref resolution itself instead of an interceptor like ComponentInterceptor. It could delegate the actual resolution to an ExternalReferenceResolver strategy: public interface ExternalReferenceResolver { Object resolveReference(String name); } In case of WebWork2 being the XWork environment, ServletDispatcher could determine the ExternalReferenceResolver implementation class name from a servlet init-param. The Spring implementation for a web environment would simply retrieve the root web application context via the ServletContext then, possibly receiving the latter via a ServletContextAware interface. public class SpringServletContextReferenceResolver implements ExternalReferenceResolver, ServletContextAware { private void ApplicationContext applicationContext; public void setServletContext(ServletContext servletContext) { this.applicationContext = WebApplicationContextUtils.getWebApplicationContext(servletContext); } public Object resolveReference(String name) { return this.applicationContext.getBean(name); } } The Spring root web application context would be loaded on startup via Spring's ContextLoaderListener, as usual. Spring/WebWork2 web apps would thus just use Spring's typical "WEB-INF/applicationContext.xml" for defining middle tier resources and business objects plus XWork's "xwork.xml" for defining use-case-driven actions. ThereÂs no "components.xml" involved, except if the web app uses XWork's scoped components mechanism too. That would keep configuration simple and concise enough for typical needs. The Spring application context will always be an application-level singleton. In a WebWork2 combo, there are no nested application contexts from a Spring web MVC DispatcherServlet involved -- WebWork2 serves as web MVC framework then. Note that an application context can create either singleton beans or new instances from a prototype, configurable via the bean definition. The external reference mechanism above would not need to be concerned with that distinction, it could transparently work with both kinds; but typical middle tier objects are almost always singletons anyway. A non-web XWork dispatcher could be configured with a different Spring resolver implementation, using a ClassPathXmlApplicationContext instead of a preloaded XmlWebApplicationContext. It would look for an "applicationContext.xml" resource in the root of the class path. public class SpringClassPathReferenceResolver implements ExternalReferenceResolver { private void ApplicationContext applicationContext; public SpringClassPathReferenceResolver() { this.applicationContext = new ClassPathXmlApplicationContext("/applicationContext.xml"); } public Object resolveReference(String name) { return this.applicationContext.getBean(name); } } The whole concept is pretty orthogonal to XWork's existing scoped component approach. For example, a webshop could leverage an XWork component for a session-scoped shopping cart *and* Spring-managed business objects for loading product information and for turning that shopping cart into a persistent order. BTW, an ad-hoc solution for accessing a Spring root web application context from a WebWork action could be to make the action HttpServletRequestAware and do the application context lookup manually. That would work without special support, even on WebWork1. ... ServletContext servletContext = request.getSession().getServletContext(); ApplicationContext applicationContext = WebApplicationContextUtils.getWebApplicationContext(servletContext); MyBusinessObject businessObject = (MyBusinessObject) applicationContext.getBean("myBusinessObject"); ... Of course, an external reference resolver solution would be way preferable because it allows the actions to receive references to business objects via simple bean property setters of the business object type; no custom lookup code and especially no web dependencies in the actions necessary. What do you think? Do you see a different option for integration? I'm not keen on letting Spring touch the XWork action instances directly; that would involve double definitions in both xwork.xml and applicationContext.xml. components.xml isn't a good integration point either, as it would involve double definitions too. I believe that my proposal is straightforward and intuitive, as it applies a similar notation for both action params and external references. Of course, it introduces a new concept to xwork.xml -- but I believe a powerful and generic one. Juergen -----UrsprÃngliche Nachricht----- Von: Matthew E. Porter [mailto:[EMAIL PROTECTED] Gesendet: Fr 24.10.2003 22:23 An: jÃrgen hÃller [werk3AT] Cc: Betreff: Re: XWork/Spring integration JÃergen: I may start working on the spring-ww2 integration this weekend if I get some time. I have some questions about this proposal and how the system will work. Please forgive me if these questions seem rudimentary, as I am still learning Spring. Are you talking about adding the "external-ref" tag to components.xml? In this case, I would assume it would replace the 3 scope concept in XW with Spring's application and Web-MVC scope. Or am I just wrong? How would Actions be wired in? Cheers, matthew On Thursday, October 9, 2003, at 12:16 PM, jÃrgen hÃller [werk3AT] wrote: > Matthew, Mike, > > Hmmm, I'm not always too keen in terms of perception... anyway: Hi > Matthew, I don't think I can to tell you anything about Conductor that > you wouldn't already know ;-) > > In terms of effort, I expect my XWork proposal to be pretty > straightforward to implement: It's basically just about introducing > the "external-ref" tag and an "ExternalReferenceResolver" interface > that the tag delegates to. A Spring implementation of that interface > should be easy to do too: Load the application context in some init > method, and resolve the references as bean names in the context. > > The only issue is where to load the application context from: If this > should be possible from the WEB-INF directory, we would need a > reference to the ServletContext in the SpringReferenceResolver > implementation. Else, we could use ClassPathXmlApplicationContext to > load the XML file from the class path: This would not involve anything > special at all. > > So in fact, the interface would need an init method: > > public interface ExternalReferenceResolver { > void init(); > Object resolveReference(String name); > } > > A Spring implementation could look as follows: > > public class SpringReferenceResolver implements > ExternalReferenceResolver { > private ApplicationContext applicationContext; > public void init() { > applicationContext = new > ClassPathXmlApplicationContext("/spring-context.xml"); > } > public Object resolveReference(String name) { > return applicationContext.getBean(name); > } > } > > It doesn't need to be more complicated than this. We would just need > to introduce such external reference hooks in XWork. I do not consider > an "external-ref" tag as much extra XML; and it's easy to specify > references to specific bean instances with it. What do you think? > > Juergen > > > -----Original Message----- > From: jÃrgen hÃller [werk3AT] > Sent: Thursday, October 09, 2003 6:33 PM > To: Matthew E. Porter > Cc: [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: [Springframework-developer] RE: [Springframework-user] > Introduction and Hibernate-Spring queries > > > Not yet. Maybe Mike can comment on a timeframe, although Jason might > be the one that actually works on it. Note that this plan is not fixed > at all; currently, XWork has its own enable-interface-centric simple > IoC support. I'm just "consulting" on this issue; Mike, Jason, and the > other XWork guys will have to decide on what to adopt in the end. > > Juergen > > > -----Original Message----- > From: Matthew E. Porter [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 09, 2003 6:31 PM > To: jÃrgen hÃller [werk3AT] > Cc: [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: [Springframework-user] Introduction and Hibernate-Spring > queries > > > Has any work (i.e. code) been done on this? > > > Cheers, > matthew > > On Thursday, October 9, 2003, at 11:15 AM, jÃrgen hÃller [werk3AT] > wrote: > >> Matthew, everybody, >> >> My XWork/Spring integration proposal is no secret -- here it is, cut >> from a recent mail to Jason and Mike. We've been discussing IoC >> options for XWork/Conductor for quite a while, mainly in terms of >> PicoContainer vs Spring. >> >> <quote> >> >> As far as I see, the XWork config file supports setting bean >> properties as parameters on actions like this: >> >> <action name="Bar" class="com.opensymphony.xwork.SimpleAction"> >> <param name="foo">17</param> >> <param name="bar">23</param> >> </action> >> >> This is obviously pretty similar to a Spring bean definition, just >> specific for a WebWork action. A significant difference is that the >> Spring property tag can tag either a value tag or a ref tag within, >> i.e. either specify a parameter value or aÂdependency on another bean. >> >> Currently, I see the easiest way of accessing a Spring context from >> XWork via a tag that resolves an external component reference, a la: >> >> <action name="Bar" class="com.opensymphony.xwork.SimpleAction"> >> <param name="foo">17</param> >> <external-ref name="bar">myDataSource</external-ref> >> </action> >> >> XWork could fetch the Spring context then, look up the bean named >> "myDataSource", and set the reference into the "bar" bean property of >> the "Bar" action. This would be intuitive, as it works analogously to >> setting a parameter value, and flexible, as it allows to reference any >> specific instance. Effectively, you would be accessing beans in a >> Spring middle tier context rather than letting Spring touch your >> action instances - but that's not a disadvantage, rather a clean >> separation of responsibilities. >> >> Of course, the Spring support for such external references can be >> pluggable in XWork, potentially replacing the current ComponentManager >> mechanism with its enabler interfaces. Any such resolver for external >> references would simply need to return an object for the given >> symbolic name. The interface could look like this: >> >> public interface ExternalReferenceResolver { >> Object resolveReference(String name); >> } >> >> A Spring implementation would grab a reference to the Spring >> application context and call getBean with the given name. The >> application context itself could get initialized on XWork startup, >> initializing its singletons upfront. I consider such an XWork/Spring >> integration as pretty simple but very powerful: no enabler interfaces, >> just bean properties with component types, and an external-ref tag in >> addition to the param tag. >> >> </quote> >> >> Juergen >> >> >> -----Original Message----- >> From: Matthew E. Porter [mailto:[EMAIL PROTECTED] >> Sent: Thursday, October 09, 2003 4:16 PM >> To: jÃrgen hÃller [werk3AT] >> Subject: Re: [Springframework-user] Introduction and Hibernate-Spring >> queries >> >> >>> >>> Throwing in Spring as middle tier glue is a good idea, of course :-) >>> Have you already thought about my proposal regarding XWork/Spring >>> integration from some days ago? Finally, we're of course open for any >>> suggestions and enhancement requests on the Spring side of things! >>> >> >> I this proposal in the public space. I would also like to see >> XW/WW2-Spring integration in the near term future. >> >> >> Cheers, >> matthew >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > SourceForge.net hosts over 70,000 Open Source Projects. > See the people who have HELPED US provide better services: > Click here: http://sourceforge.net/supporters.php > _______________________________________________ > Springframework-developer mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/springframework-developer NHY??X'u?Cv?+j`?GRxZ+?+)~ztâ x?y(nbvvu?~?*'jX)brH^mqz?v{)~{ +?zZ)zXX*kxÂÅu?^X(â~zwilqzlX)?))~{ +?zZ)