Menu
▾
▴
Re: [Springframework-developer] Re: XWork/Spring integration
|
From: Cameron B. <ca...@da...> - 2003-10-26 09:13:36
|
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:ma...@me...]
> 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: spr...@li...;
> > spr...@li...
> > 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:ma...@me...]
> > Sent: Thursday, October 09, 2003 6:31 PM
> > To: jürgen höller [werk3AT]
> > Cc: spr...@li...;
> > spr...@li...
> > 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:ma...@me...]
> >> 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
> > Spr...@li...
> > 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)
|
