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)
