springframework-developer

Re: [Springframework-developer] Re: WebWork2 integration (was: About MVC)

[<jue...@we...>]

Cameron,

Wow, that was a quick reply! :-)

Your approach of using Spring as action factory for XWork, IoC-wiring =
XWork action objects, is similar to Don Brown's Struts-Spring project =
where Spring is used as action factory for Struts, IoC-wiring Struts =
action objects. I generally tend to view Spring as middle tier component =
provider rather than action factory when used with other web frameworks.

As you've noted, you typically need some kind of double configuration =
for action factory usage: Spring wires the actions and gives them a =
name, but the web framework still needs to define the actions and link =
to the Spring action factory. I totally agree that the separation is =
cleaner when just accessing Spring components from such actions. The =
latter would also seamlessly allow for a Spring root web application =
context (with middle tier components) being accessed by various =
dispatcher servlets (with web actions), even by multiple different web =
MVC frameworks within the same web application!

The <ref>/ReferenceResolver idea should be easy to add to XWork, after =
all. XWork already has reflection-based setting of <param> parameters; =
<ref> references could use the very same mechanism. A =
SpringServletContextReferenceResolver for WebWork2 could fetch the =
ServletContext from a ThreadLocal, grab the root WebApplicationContext =
from the ServletContext, and resolve the reference name as bean name. A =
non-web SpringClassPathReferenceResolver could access a pre-loaded =
ClassPathXmlApplicationContext from a ThreadLocal, and resolve the =
reference name as bean name there.

I would be delighted to see that approach being adopted in =
XWork/WebWork2, as it would allow for a really nice and straightforward =
combination. In terms of timing, it would be good to settle that before =
both Spring 1.0 final (end of December) and WebWork2 final (any =
timeframe there?). I'm happy to help on the Spring side of things, but I =
guess we won't need any changes in Spring to allow for that kind of =
reference support in XWork.

Juergen


-----Original Message-----
From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Cameron Braid
Sent: Wednesday, November 12, 2003 12:36 PM
To: spr...@li...
Subject: [[W3-SPAM]] - Re: [Springframework-developer] Re: WebWork2 =
integration (was: About MVC) - Email found in subject


j=FCrgen h=F6ller [werk3AT] wrote:

Hi Lars,

Cameron Braid has been working on XWork/WebWork2 integration and =
obviously been pleased with it (you can search our mailing list archives =
for the whole thread).

<quote>
The bean/@id attribute relaxing is fantastic thanks!

I can now use the Spring Framework as an Action Factory for=20
Xwork/WebWork with no duplcation of configuration, using spring to=20
define business related interceptors : components, transactions,=20
security and webwork to provide web/view oriented interceptors :=20
request-params, validation

xwork.xml snippet :

<package name=3D"admin" namespace=3D"/admin" extends=3D"default">
  <action name=3D"update" class=3D"com.project.AdminUpdateAction" =
method=3D"txUpdate">
    <result name=3D"redirect">read.action?id=3D${id}</result>
  </action>
</package>

applicationContext.xml snippet :

<bean name=3D"/admin/update" =
class=3D"com.datacodex.spring.webwork.WebworkActionFactoryBean">
  <property name=3D"sessionFactory">
    <ref local=3D"sessionFactory"/>
  </property>
  <property name=3D"transactionManager">
    <ref local=3D"transactionManager"/>
  </property>
  <property name=3D"transactionAttributes">
    <ref local=3D"defaultActionTransactionAttributes"/>
  </property>
</bean>

very simple, neat and clean !

Thanks guys for your fantastic framework.

Cameron.
</quote>

I don't know how his integration approach works in detail but it looks =
promising. Cameron, can you give any in-depth insights? I assume the =
WebworkActionFactoryBean creates the action, being given the class name =
from the XWork definition? How does XWork know that it needs to delegate =
to the corresponding WebWorkActionFactoryBean - I guess via some custom =
XWork action factory? How does that action factory look up the Spring =
application context?

 =20
I have made a few posts on the webwork mailing list.

See =
http://www.mail-archive.com/ope...@li.../ms=
g05919.html to start the thread - since then I have attempted to =
implement some of these ideas.

A basic summary :

I extended the WebWork ServletDispatcher, writing a new =
SpringServletDispatcher, it makes a call to the static =
ActionProxyFactory.setFactory(new=20
SpringActionProxyFactory()). =20

SpringActionProxyFactory extends the DefaultActionProxyFactory which =
overrides createActionInvocation to use=20
a SpringActionInvocation

  SpringActionInvocation extends DefaultActionInvocation which overrides =
createAction to delegate to =
WebApplicationContextUtils.getWebApplicationContext(servletContext).getBe=
an(beanName)=20
to use the factory within spring to contruct this action.

The servletContext is obtained using a webwork static helper that =
retrieves it from the action context (threadlocal)

This level of integration is only required if you want to use spring as =
the action factory.

Most often you will only want to use spring to provide the components =
that the actions use, which I think is a better soloution.


As an alternative, I still see value in extending XWork's XML action =
definition format with a <ref> tag, in addition to the existing <param> =
tag. Those ref tags could then get resolved via a ReferenceResolver =
interface, possibly with a SpringReferenceResolver implementation that =
looks up the reference names in an application context. I've suggested =
that a while ago, but I don't think that anyone has adopted the idea =
yet, as it involves an extension of the XWork core.

 =20
I really like your idea of supporting an external ref type tag as core =
in xwork/webwork since it offers the simplest, and most elegent =
soloution.

<action name=3D"listAccounts" class=3D"project.controller.ListAccounts">
   ...
    <ref name=3D"accountsDao">accountsDao</ref>
   ...
</action>
Using one of these later ideas means that the action and refrences are =
totally defined in the webwork configuration, and components are defined =
in spring, which is a good separation in my mind.

When using spring as the action facory I was starting to find it =
difficult to see what was going on in regards to the actions since some =
configuration was done in xwork.xml and some in the spring context.

I can have a go at adding <ref> support to the xwork configuration code =
- in my snadbox.  In the meantime we can discuss further and see what =
the other webwork developers think.

Before reading about this idea, I implemented a simple prototype (not =
production ready) system to get components from spring using a webwork =
interceptor. =20

What happens here is you configure the interceptor in the xwork.xml file =
just like any other webwork interceptor, using parameter to provide a =
mapping of action proeprty to spring bean name.

see =
http://www.mail-archive.com/ope...@li.../ms=
g05957.html

A basic summary :

<action name=3D"listAccounts" class=3D"project.controller.ListAccounts">
   ...
    <interceptor-ref name=3D"springComponent">
       <param name=3D"mapping">
            accountsDao=3DaccountsDao
       </param>
   </interceptor-ref>
   ...
</action>
this example reflectively invokes =
action.setAccountsDao(WebApplicationContextUtils.getWebApplicationContext=
(servletContext).getBean(beanName))
obtaining the servlet context from the action context.

I would prefer to use the <ref> tag since it is a lot more meaningful, =
and allows for plugable RefrenceResolvers .

Thanks,

Cameron


Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Lars Fischer
Sent: Wednesday, November 12, 2003 11:32 AM
To: spr...@li...
Subject: [[W3-SPAM]] - RE: [Springframework-developer] About MVC - Email
found in subject


I think it would be a good idea to put a focus on WebWork 2 integration.
WebWork is a very popular framework and I think Spring would gain
further popularity when providing a way to integrate WebWork "out of the
box".

IMO the main advantage of WebWork is that it's very easy to understand =
even
with missing documentation. Spring MVC maybe technically superior
(I don't know) but it's too complicated to get started with.

The combination of Spring as Container and WebWork 2 as MVC framework
is very powerful.

What do you think about this ?

Regards,
Lars

Re: [Springframework-developer] Re: WebWork2 integration (was: About MVC)

[Mike Cannon-B. <mi...@at...>]

> The <ref>/ReferenceResolver idea should be easy to add to XWork, after al=
l.
> XWork already has reflection-based setting of <param> parameters; <ref>
> references could use the very same mechanism. A
> SpringServletContextReferenceResolver for WebWork2 could fetch the
> ServletContext from a ThreadLocal, grab the root WebApplicationContext fr=
om
> the ServletContext, and resolve the reference name as bean name. A non-we=
b
> SpringClassPathReferenceResolver could access a pre-loaded
> ClassPathXmlApplicationContext from a ThreadLocal, and resolve the refere=
nce
> name as bean name there.
Wow - I should read the whole thread before replying :)

As said, Ross has finished this now - we're just testing and integrating
into the application before committing it back to XWork.

At the moment it works as follows (please correct me if I've got anything
wrong Ross).

There is an ExternalEntityResolver defined on a per package level, so that
you can have different resolvers for different packages (if needed). These
are hierarchically looked up too, so if you specify one for the default
package, it will filter down to all other packages.

Each action can then specify external references to be resolved, as follows=
:

<package name=3D"admin" namespace=3D"/admin" extends=3D"default"
  external-ref-resolver=3D"com.foo.SpringExternalReferenceResolver">
  <action name=3D"update" class=3D"com.Foo">
    <external-ref name=3D"pageManager">myPageManager</external-ref>
  </action>

There is then a single XWork interceptor for all resolver implementations
(com.opensymphony.xwork.interceptors.ExternalReferenceResolutionInterceptor=
?
). This hands off to the resolver implementation to actually do the
resolution (ie look up "myPageManager" from the Spring context, and then se=
t
it using setPageManager(object) on the action instance).

I believe there were a few modifications to the XWork core needed to make i=
t
work nicely (such as being able to retrieve a PackageConfig from an
ActionConfig to lookup the resolver), but it all hangs together very nicely=
.

The benefit of resolution being in an interceptor, like all the Xwork
interceptors, is that you can then as the developer control the order in
which your action is setup (ie external references, XWork IoC components,
static parameters, web parameters etc).
 =20
> I would be delighted to see that approach being adopted in XWork/WebWork2=
, as
> it would allow for a really nice and straightforward combination. In term=
s of
> timing, it would be good to settle that before both Spring 1.0 final (end=
 of
> December) and WebWork2 final (any timeframe there?). I'm happy to help on=
 the
> Spring side of things, but I guess we won't need any changes in Spring to
> allow for that kind of reference support in XWork.

The only thing I think we decided that would be handy from the Spring side
(that doesn't exist) is the ability to autoconfigure an existing object?

This would consist of giving an object and a series of names (or other
objects?) to the context, and it then working out how they are best
autowired together. This would mean you wouldn't necessarily need the
name=3D"" in the external reference (at the cost of a little speed I suppose)
- but useful for lots of resolutions.

Hope it makes sense.

Cheers,
Mike

> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf O=
f
> Cameron Braid
> Sent: Wednesday, November 12, 2003 12:36 PM
> To: spr...@li...
> Subject: [[W3-SPAM]] - Re: [Springframework-developer] Re: WebWork2
> integration (was: About MVC) - Email found in subject
>=20
>=20
> j=FCrgen h=F6ller [werk3AT] wrote:
>=20
> Hi Lars,
>=20
> Cameron Braid has been working on XWork/WebWork2 integration and obviousl=
y
> been pleased with it (you can search our mailing list archives for the wh=
ole
> thread).
>=20
> <quote>
> The bean/@id attribute relaxing is fantastic thanks!
>=20
> I can now use the Spring Framework as an Action Factory for
> Xwork/WebWork with no duplcation of configuration, using spring to
> define business related interceptors : components, transactions,
> security and webwork to provide web/view oriented interceptors :
> request-params, validation
>=20
> xwork.xml snippet :
>=20
> <package name=3D"admin" namespace=3D"/admin" extends=3D"default">
> <action name=3D"update" class=3D"com.project.AdminUpdateAction" method=3D"txUpd=
ate">
>   <result name=3D"redirect">read.action?id=3D${id}</result>
> </action>
> </package>
>=20
> applicationContext.xml snippet :
>=20
> <bean name=3D"/admin/update"
> class=3D"com.datacodex.spring.webwork.WebworkActionFactoryBean">
> <property name=3D"sessionFactory">
>   <ref local=3D"sessionFactory"/>
> </property>
> <property name=3D"transactionManager">
>   <ref local=3D"transactionManager"/>
> </property>
> <property name=3D"transactionAttributes">
>   <ref local=3D"defaultActionTransactionAttributes"/>
> </property>
> </bean>
>=20
> very simple, neat and clean !
>=20
> Thanks guys for your fantastic framework.
>=20
> Cameron.
> </quote>
>=20
> I don't know how his integration approach works in detail but it looks
> promising. Cameron, can you give any in-depth insights? I assume the
> WebworkActionFactoryBean creates the action, being given the class name f=
rom
> the XWork definition? How does XWork know that it needs to delegate to th=
e
> corresponding WebWorkActionFactoryBean - I guess via some custom XWork ac=
tion
> factory? How does that action factory look up the Spring application cont=
ext?
>=20
>=20
> I have made a few posts on the webwork mailing list.
>=20
> See=20
> http://www.mail-archive.com/ope...@li.../ms=
g0591
> 9.html to start the thread - since then I have attempted to implement som=
e of
> these ideas.
>=20
> A basic summary :
>=20
> I extended the WebWork ServletDispatcher, writing a new
> SpringServletDispatcher, it makes a call to the static
> ActionProxyFactory.setFactory(new
> SpringActionProxyFactory()).
>=20
> SpringActionProxyFactory extends the DefaultActionProxyFactory which over=
rides
> createActionInvocation to use
> a SpringActionInvocation
>=20
> SpringActionInvocation extends DefaultActionInvocation which overrides
> createAction to delegate to
> WebApplicationContextUtils.getWebApplicationContext(servletContext).getBe=
an(be
> anName)=20
> to use the factory within spring to contruct this action.
>=20
> The servletContext is obtained using a webwork static helper that retriev=
es it
> from the action context (threadlocal)
>=20
> This level of integration is only required if you want to use spring as t=
he
> action factory.
>=20
> Most often you will only want to use spring to provide the components tha=
t the
> actions use, which I think is a better soloution.
>=20
>=20
> As an alternative, I still see value in extending XWork's XML action
> definition format with a <ref> tag, in addition to the existing <param> t=
ag.
> Those ref tags could then get resolved via a ReferenceResolver interface,
> possibly with a SpringReferenceResolver implementation that looks up the
> reference names in an application context. I've suggested that a while ag=
o,
> but I don't think that anyone has adopted the idea yet, as it involves an
> extension of the XWork core.
>=20
>=20
> I really like your idea of supporting an external ref type tag as core in
> xwork/webwork since it offers the simplest, and most elegent soloution.
>=20
> <action name=3D"listAccounts" class=3D"project.controller.ListAccounts">
>  ...
>   <ref name=3D"accountsDao">accountsDao</ref>
>  ...
> </action>
> Using one of these later ideas means that the action and refrences are to=
tally
> defined in the webwork configuration, and components are defined in sprin=
g,
> which is a good separation in my mind.
>=20
> When using spring as the action facory I was starting to find it difficul=
t to
> see what was going on in regards to the actions since some configuration =
was
> done in xwork.xml and some in the spring context.
>=20
> I can have a go at adding <ref> support to the xwork configuration code -=
 in
> my snadbox.  In the meantime we can discuss further and see what the othe=
r
> webwork developers think.
>=20
> Before reading about this idea, I implemented a simple prototype (not
> production ready) system to get components from spring using a webwork
> interceptor. =20
>=20
> What happens here is you configure the interceptor in the xwork.xml file =
just
> like any other webwork interceptor, using parameter to provide a mapping =
of
> action proeprty to spring bean name.
>=20
> see=20
> http://www.mail-archive.com/ope...@li.../ms=
g0595
> 7.html
>=20
> A basic summary :
>=20
> <action name=3D"listAccounts" class=3D"project.controller.ListAccounts">
>  ...
>   <interceptor-ref name=3D"springComponent">
>      <param name=3D"mapping">
>           accountsDao=3DaccountsDao
>      </param>
>  </interceptor-ref>
>  ...
> </action>
> this example reflectively invokes
> action.setAccountsDao(WebApplicationContextUtils.getWebApplicationContext=
(serv
> letContext).getBean(beanName))
> obtaining the servlet context from the action context.
>=20
> I would prefer to use the <ref> tag since it is a lot more meaningful, an=
d
> allows for plugable RefrenceResolvers .
>=20
> Thanks,
>=20
> Cameron
>=20
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Lars Fischer
> Sent: Wednesday, November 12, 2003 11:32 AM
> To: spr...@li...
> Subject: [[W3-SPAM]] - RE: [Springframework-developer] About MVC - Email
> found in subject
>=20
>=20
> I think it would be a good idea to put a focus on WebWork 2 integration.
> WebWork is a very popular framework and I think Spring would gain
> further popularity when providing a way to integrate WebWork "out of the
> box".
>=20
> IMO the main advantage of WebWork is that it's very easy to understand ev=
en
> with missing documentation. Spring MVC maybe technically superior
> (I don't know) but it's too complicated to get started with.
>=20
> The combination of Spring as Container and WebWork 2 as MVC framework
> is very powerful.
>=20
> What do you think about this ?
>=20
> Regards,
> Lars
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: WebWork2 integration (was: About MVC)

[Cameron B. <ca...@da...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
This sounds fantastic.&nbsp; I am really keen to see this in action.<br>
<br>
Any idea of when it may be availible ?&nbsp; If it is likely to be more than
a week, and if you have the time, could you send me a patchfile against
xwork head, and I'll apply it to a snapshot here.<br>
<br>
Thanks.<br>
<br>
Cameron<br>
<br>
Mike Cannon-Brookes wrote:<br>
<blockquote type="cite" cite="midBBD87A92.3A318%25...@at...">
  <blockquote type="cite">
    <pre wrap="">The &lt;ref&gt;/ReferenceResolver idea should be easy to add to XWork, after all.
XWork already has reflection-based setting of &lt;param&gt; parameters; &lt;ref&gt;
references could use the very same mechanism. A
SpringServletContextReferenceResolver for WebWork2 could fetch the
ServletContext from a ThreadLocal, grab the root WebApplicationContext from
the ServletContext, and resolve the reference name as bean name. A non-web
SpringClassPathReferenceResolver could access a pre-loaded
ClassPathXmlApplicationContext from a ThreadLocal, and resolve the reference
name as bean name there.
    </pre>
  </blockquote>
  <pre wrap=""><!---->Wow - I should read the whole thread before replying :)

As said, Ross has finished this now - we're just testing and integrating
into the application before committing it back to XWork.

At the moment it works as follows (please correct me if I've got anything
wrong Ross).

There is an ExternalEntityResolver defined on a per package level, so that
you can have different resolvers for different packages (if needed). These
are hierarchically looked up too, so if you specify one for the default
package, it will filter down to all other packages.

Each action can then specify external references to be resolved, as follows:

&lt;package name="admin" namespace="/admin" extends="default"
  external-ref-resolver="com.foo.SpringExternalReferenceResolver"&gt;
  &lt;action name="update" class="com.Foo"&gt;
    &lt;external-ref name="pageManager"&gt;myPageManager&lt;/external-ref&gt;
  &lt;/action&gt;

There is then a single XWork interceptor for all resolver implementations
(com.opensymphony.xwork.interceptors.ExternalReferenceResolutionInterceptor?
). This hands off to the resolver implementation to actually do the
resolution (ie look up "myPageManager" from the Spring context, and then set
it using setPageManager(object) on the action instance).

I believe there were a few modifications to the XWork core needed to make it
work nicely (such as being able to retrieve a PackageConfig from an
ActionConfig to lookup the resolver), but it all hangs together very nicely.

The benefit of resolution being in an interceptor, like all the Xwork
interceptors, is that you can then as the developer control the order in
which your action is setup (ie external references, XWork IoC components,
static parameters, web parameters etc).
  
  </pre>
  <blockquote type="cite">
    <pre wrap="">I would be delighted to see that approach being adopted in XWork/WebWork2, as
it would allow for a really nice and straightforward combination. In terms of
timing, it would be good to settle that before both Spring 1.0 final (end of
December) and WebWork2 final (any timeframe there?). I'm happy to help on the
Spring side of things, but I guess we won't need any changes in Spring to
allow for that kind of reference support in XWork.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
The only thing I think we decided that would be handy from the Spring side
(that doesn't exist) is the ability to autoconfigure an existing object?

This would consist of giving an object and a series of names (or other
objects?) to the context, and it then working out how they are best
autowired together. This would mean you wouldn't necessarily need the
name="" in the external reference (at the cost of a little speed I suppose)
- but useful for lots of resolutions.

Hope it makes sense.

Cheers,
Mike

  </pre>
  <blockquote type="cite">
    <pre wrap="">Juergen


-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:spr...@li...">spr...@li...</a>
[<a class="moz-txt-link-freetext" href="mailto:spr...@li...">mailto:spr...@li...</a>]On Behalf Of
Cameron Braid
Sent: Wednesday, November 12, 2003 12:36 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:spr...@li...">spr...@li...</a>
Subject: [[W3-SPAM]] - Re: [Springframework-developer] Re: WebWork2
integration (was: About MVC) - Email found in subject


j&uuml;rgen h&ouml;ller [werk3AT] wrote:

Hi Lars,

Cameron Braid has been working on XWork/WebWork2 integration and obviously
been pleased with it (you can search our mailing list archives for the whole
thread).

&lt;quote&gt;
The bean/@id attribute relaxing is fantastic thanks!

I can now use the Spring Framework as an Action Factory for
Xwork/WebWork with no duplcation of configuration, using spring to
define business related interceptors : components, transactions,
security and webwork to provide web/view oriented interceptors :
request-params, validation

xwork.xml snippet :

&lt;package name="admin" namespace="/admin" extends="default"&gt;
&lt;action name="update" class="com.project.AdminUpdateAction" method="txUpdate"&gt;
  &lt;result name="redirect"&gt;read.action?id=${id}&lt;/result&gt;
&lt;/action&gt;
&lt;/package&gt;

applicationContext.xml snippet :

&lt;bean name="/admin/update"
class="com.datacodex.spring.webwork.WebworkActionFactoryBean"&gt;
&lt;property name="sessionFactory"&gt;
  &lt;ref local="sessionFactory"/&gt;
&lt;/property&gt;
&lt;property name="transactionManager"&gt;
  &lt;ref local="transactionManager"/&gt;
&lt;/property&gt;
&lt;property name="transactionAttributes"&gt;
  &lt;ref local="defaultActionTransactionAttributes"/&gt;
&lt;/property&gt;
&lt;/bean&gt;

very simple, neat and clean !

Thanks guys for your fantastic framework.

Cameron.
&lt;/quote&gt;

I don't know how his integration approach works in detail but it looks
promising. Cameron, can you give any in-depth insights? I assume the
WebworkActionFactoryBean creates the action, being given the class name from
the XWork definition? How does XWork know that it needs to delegate to the
corresponding WebWorkActionFactoryBean - I guess via some custom XWork action
factory? How does that action factory look up the Spring application context?


I have made a few posts on the webwork mailing list.

See 
<a class="moz-txt-link-freetext" href="http://www.mail-archive.com/ope...@li.../msg0591">http://www.mail-archive.com/ope...@li.../msg0591</a>
9.html to start the thread - since then I have attempted to implement some of
these ideas.

A basic summary :

I extended the WebWork ServletDispatcher, writing a new
SpringServletDispatcher, it makes a call to the static
ActionProxyFactory.setFactory(new
SpringActionProxyFactory()).

SpringActionProxyFactory extends the DefaultActionProxyFactory which overrides
createActionInvocation to use
a SpringActionInvocation

SpringActionInvocation extends DefaultActionInvocation which overrides
createAction to delegate to
WebApplicationContextUtils.getWebApplicationContext(servletContext).getBean(be
anName) 
to use the factory within spring to contruct this action.

The servletContext is obtained using a webwork static helper that retrieves it
from the action context (threadlocal)

This level of integration is only required if you want to use spring as the
action factory.

Most often you will only want to use spring to provide the components that the
actions use, which I think is a better soloution.


As an alternative, I still see value in extending XWork's XML action
definition format with a &lt;ref&gt; tag, in addition to the existing &lt;param&gt; tag.
Those ref tags could then get resolved via a ReferenceResolver interface,
possibly with a SpringReferenceResolver implementation that looks up the
reference names in an application context. I've suggested that a while ago,
but I don't think that anyone has adopted the idea yet, as it involves an
extension of the XWork core.


I really like your idea of supporting an external ref type tag as core in
xwork/webwork since it offers the simplest, and most elegent soloution.

&lt;action name="listAccounts" class="project.controller.ListAccounts"&gt;
 ...
  &lt;ref name="accountsDao"&gt;accountsDao&lt;/ref&gt;
 ...
&lt;/action&gt;
Using one of these later ideas means that the action and refrences are totally
defined in the webwork configuration, and components are defined in spring,
which is a good separation in my mind.

When using spring as the action facory I was starting to find it difficult to
see what was going on in regards to the actions since some configuration was
done in xwork.xml and some in the spring context.

I can have a go at adding &lt;ref&gt; support to the xwork configuration code - in
my snadbox.  In the meantime we can discuss further and see what the other
webwork developers think.

Before reading about this idea, I implemented a simple prototype (not
production ready) system to get components from spring using a webwork
interceptor.  

What happens here is you configure the interceptor in the xwork.xml file just
like any other webwork interceptor, using parameter to provide a mapping of
action proeprty to spring bean name.

see 
<a class="moz-txt-link-freetext" href="http://www.mail-archive.com/ope...@li.../msg0595">http://www.mail-archive.com/ope...@li.../msg0595</a>
7.html

A basic summary :

&lt;action name="listAccounts" class="project.controller.ListAccounts"&gt;
 ...
  &lt;interceptor-ref name="springComponent"&gt;
     &lt;param name="mapping"&gt;
          accountsDao=accountsDao
     &lt;/param&gt;
 &lt;/interceptor-ref&gt;
 ...
&lt;/action&gt;
this example reflectively invokes
action.setAccountsDao(WebApplicationContextUtils.getWebApplicationContext(serv
letContext).getBean(beanName))
obtaining the servlet context from the action context.

I would prefer to use the &lt;ref&gt; tag since it is a lot more meaningful, and
allows for plugable RefrenceResolvers .

Thanks,

Cameron


Juergen


-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:spr...@li...">spr...@li...</a>
[<a class="moz-txt-link-freetext" href="mailto:spr...@li...">mailto:spr...@li...</a>]On Behalf
Of Lars Fischer
Sent: Wednesday, November 12, 2003 11:32 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:spr...@li...">spr...@li...</a>
Subject: [[W3-SPAM]] - RE: [Springframework-developer] About MVC - Email
found in subject


I think it would be a good idea to put a focus on WebWork 2 integration.
WebWork is a very popular framework and I think Spring would gain
further popularity when providing a way to integrate WebWork "out of the
box".

IMO the main advantage of WebWork is that it's very easy to understand even
with missing documentation. Spring MVC maybe technically superior
(I don't know) but it's too complicated to get started with.

The combination of Spring as Container and WebWork 2 as MVC framework
is very powerful.

What do you think about this ?

Regards,
Lars


-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! <a class="moz-txt-link-freetext" href="http://www.apachecon.com/">http://www.apachecon.com/</a>
_______________________________________________
Springframework-developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Spr...@li...">Spr...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/springframework-developer">https://lists.sourceforge.net/lists/listinfo/springframework-developer</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->


-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! <a class="moz-txt-link-freetext" href="http://www.apachecon.com/">http://www.apachecon.com/</a>
_______________________________________________
Springframework-developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Spr...@li...">Spr...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/springframework-developer">https://lists.sourceforge.net/lists/listinfo/springframework-developer</a>

  </pre>
</blockquote>
<br>
<br>
<pre cols="72" class="moz-signature">-- 
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler <a class="moz-txt-link-freetext" href="http://www.martinfowler.com/distributedComputing/refactoring.pdf">http://www.martinfowler.com/distributedComputing/refactoring.pdf</a>]</pre>
</body>
</html>

Re: [Springframework-developer] Re: WebWork2 integration (was: About MVC)

[Rod J. <rod...@in...>]

I think it's important that we get out the message that, although Spring
does have a good MVC framework itself, it isn't a monolithic solution. From
what I've seen of it, WW is an elegant framework (unlike certain others in
its space) and, as with Hibernate, we should make it easy for users to
combine Spring and WW. Hopefully both we and the WW community can help to
support such users.

Same goes for Tapestry.

Of course Struts integration is also going to continue to come up, and it's
good that there's another project out there focusing on it. Although we
should encourage Struts users to look at Spring MVC.

We probably need a "Using Spring with Struts" article or tutorial, as
numerous people have asked.

Regards,
Rod

----- Original Message ----- 
From: "Cameron Braid" <ca...@da...>
To: <spr...@li...>
Sent: Wednesday, November 12, 2003 3:51 PM
Subject: Re: [Springframework-developer] Re: WebWork2 integration (was:
About MVC)


> This sounds fantastic.  I am really keen to see this in action.
>
> Any idea of when it may be availible ?  If it is likely to be more than a
week, and if you have the time, could you send me a patchfile against xwork
head, and I'll apply it to a snapshot here.
>
> Thanks.
>
> Cameron
>
> Mike Cannon-Brookes wrote:
>
> The <ref>/ReferenceResolver idea should be easy to add to XWork, after
all.
> XWork already has reflection-based setting of <param> parameters; <ref>
> references could use the very same mechanism. A
> SpringServletContextReferenceResolver for WebWork2 could fetch the
> ServletContext from a ThreadLocal, grab the root WebApplicationContext
from
> the ServletContext, and resolve the reference name as bean name. A non-web
> SpringClassPathReferenceResolver could access a pre-loaded
> ClassPathXmlApplicationContext from a ThreadLocal, and resolve the
reference
> name as bean name there.
>     Wow - I should read the whole thread before replying :)
>
> As said, Ross has finished this now - we're just testing and integrating
> into the application before committing it back to XWork.
>
> At the moment it works as follows (please correct me if I've got anything
> wrong Ross).
>
> There is an ExternalEntityResolver defined on a per package level, so that
> you can have different resolvers for different packages (if needed). These
> are hierarchically looked up too, so if you specify one for the default
> package, it will filter down to all other packages.
>
> Each action can then specify external references to be resolved, as
follows:
>
> <package name="admin" namespace="/admin" extends="default"
>   external-ref-resolver="com.foo.SpringExternalReferenceResolver">
>   <action name="update" class="com.Foo">
>     <external-ref name="pageManager">myPageManager</external-ref>
>   </action>
>
> There is then a single XWork interceptor for all resolver implementations
>
(com.opensymphony.xwork.interceptors.ExternalReferenceResolutionInterceptor?
> ). This hands off to the resolver implementation to actually do the
> resolution (ie look up "myPageManager" from the Spring context, and then
set
> it using setPageManager(object) on the action instance).
>
> I believe there were a few modifications to the XWork core needed to make
it
> work nicely (such as being able to retrieve a PackageConfig from an
> ActionConfig to lookup the resolver), but it all hangs together very
nicely.
>
> The benefit of resolution being in an interceptor, like all the Xwork
> interceptors, is that you can then as the developer control the order in
> which your action is setup (ie external references, XWork IoC components,
> static parameters, web parameters etc).
>
>   I would be delighted to see that approach being adopted in
XWork/WebWork2, as
> it would allow for a really nice and straightforward combination. In terms
of
> timing, it would be good to settle that before both Spring 1.0 final (end
of
> December) and WebWork2 final (any timeframe there?). I'm happy to help on
the
> Spring side of things, but I guess we won't need any changes in Spring to
> allow for that kind of reference support in XWork.
>
> The only thing I think we decided that would be handy from the Spring side
> (that doesn't exist) is the ability to autoconfigure an existing object?
>
> This would consist of giving an object and a series of names (or other
> objects?) to the context, and it then working out how they are best
> autowired together. This would mean you wouldn't necessarily need the
> name="" in the external reference (at the cost of a little speed I
suppose)
> - but useful for lots of resolutions.
>
> Hope it makes sense.
>
> Cheers,
> Mike
>
>   Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf Of
> Cameron Braid
> Sent: Wednesday, November 12, 2003 12:36 PM
> To: spr...@li...
> Subject: [[W3-SPAM]] - Re: [Springframework-developer] Re: WebWork2
> integration (was: About MVC) - Email found in subject
>
>
> jürgen höller [werk3AT] wrote:
>
> Hi Lars,
>
> Cameron Braid has been working on XWork/WebWork2 integration and obviously
> been pleased with it (you can search our mailing list archives for the
whole
> thread).
>
> <quote>
> The bean/@id attribute relaxing is fantastic thanks!
>
> I can now use the Spring Framework as an Action Factory for
> Xwork/WebWork with no duplcation of configuration, using spring to
> define business related interceptors : components, transactions,
> security and webwork to provide web/view oriented interceptors :
> request-params, validation
>
> xwork.xml snippet :
>
> <package name="admin" namespace="/admin" extends="default">
> <action name="update" class="com.project.AdminUpdateAction"
method="txUpdate">
>   <result name="redirect">read.action?id=${id}</result>
> </action>
> </package>
>
> applicationContext.xml snippet :
>
> <bean name="/admin/update"
> class="com.datacodex.spring.webwork.WebworkActionFactoryBean">
> <property name="sessionFactory">
>   <ref local="sessionFactory"/>
> </property>
> <property name="transactionManager">
>   <ref local="transactionManager"/>
> </property>
> <property name="transactionAttributes">
>   <ref local="defaultActionTransactionAttributes"/>
> </property>
> </bean>
>
> very simple, neat and clean !
>
> Thanks guys for your fantastic framework.
>
> Cameron.
> </quote>
>
> I don't know how his integration approach works in detail but it looks
> promising. Cameron, can you give any in-depth insights? I assume the
> WebworkActionFactoryBean creates the action, being given the class name
from
> the XWork definition? How does XWork know that it needs to delegate to the
> corresponding WebWorkActionFactoryBean - I guess via some custom XWork
action
> factory? How does that action factory look up the Spring application
context?
>
>
> I have made a few posts on the webwork mailing list.
>
> See
>
http://www.mail-archive.com/ope...@li.../msg0591
> 9.html to start the thread - since then I have attempted to implement some
of
> these ideas.
>
> A basic summary :
>
> I extended the WebWork ServletDispatcher, writing a new
> SpringServletDispatcher, it makes a call to the static
> ActionProxyFactory.setFactory(new
> SpringActionProxyFactory()).
>
> SpringActionProxyFactory extends the DefaultActionProxyFactory which
overrides
> createActionInvocation to use
> a SpringActionInvocation
>
> SpringActionInvocation extends DefaultActionInvocation which overrides
> createAction to delegate to
>
WebApplicationContextUtils.getWebApplicationContext(servletContext).getBean(
be
> anName)
> to use the factory within spring to contruct this action.
>
> The servletContext is obtained using a webwork static helper that
retrieves it
> from the action context (threadlocal)
>
> This level of integration is only required if you want to use spring as
the
> action factory.
>
> Most often you will only want to use spring to provide the components that
the
> actions use, which I think is a better soloution.
>
>
> As an alternative, I still see value in extending XWork's XML action
> definition format with a <ref> tag, in addition to the existing <param>
tag.
> Those ref tags could then get resolved via a ReferenceResolver interface,
> possibly with a SpringReferenceResolver implementation that looks up the
> reference names in an application context. I've suggested that a while
ago,
> but I don't think that anyone has adopted the idea yet, as it involves an
> extension of the XWork core.
>
>
> I really like your idea of supporting an external ref type tag as core in
> xwork/webwork since it offers the simplest, and most elegent soloution.
>
> <action name="listAccounts" class="project.controller.ListAccounts">
>  ...
>   <ref name="accountsDao">accountsDao</ref>
>  ...
> </action>
> Using one of these later ideas means that the action and refrences are
totally
> defined in the webwork configuration, and components are defined in
spring,
> which is a good separation in my mind.
>
> When using spring as the action facory I was starting to find it difficult
to
> see what was going on in regards to the actions since some configuration
was
> done in xwork.xml and some in the spring context.
>
> I can have a go at adding <ref> support to the xwork configuration code -
in
> my snadbox.  In the meantime we can discuss further and see what the other
> webwork developers think.
>
> Before reading about this idea, I implemented a simple prototype (not
> production ready) system to get components from spring using a webwork
> interceptor.
>
> What happens here is you configure the interceptor in the xwork.xml file
just
> like any other webwork interceptor, using parameter to provide a mapping
of
> action proeprty to spring bean name.
>
> see
>
http://www.mail-archive.com/ope...@li.../msg0595
> 7.html
>
> A basic summary :
>
> <action name="listAccounts" class="project.controller.ListAccounts">
>  ...
>   <interceptor-ref name="springComponent">
>      <param name="mapping">
>           accountsDao=accountsDao
>      </param>
>  </interceptor-ref>
>  ...
> </action>
> this example reflectively invokes
>
action.setAccountsDao(WebApplicationContextUtils.getWebApplicationContext(se
rv
> letContext).getBean(beanName))
> obtaining the servlet context from the action context.
>
> I would prefer to use the <ref> tag since it is a lot more meaningful, and
> allows for plugable RefrenceResolvers .
>
> Thanks,
>
> Cameron
>
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Lars Fischer
> Sent: Wednesday, November 12, 2003 11:32 AM
> To: spr...@li...
> Subject: [[W3-SPAM]] - RE: [Springframework-developer] About MVC - Email
> found in subject
>
>
> I think it would be a good idea to put a focus on WebWork 2 integration.
> WebWork is a very popular framework and I think Spring would gain
> further popularity when providing a way to integrate WebWork "out of the
> box".
>
> IMO the main advantage of WebWork is that it's very easy to understand
even
> with missing documentation. Spring MVC maybe technically superior
> (I don't know) but it's too complicated to get started with.
>
> The combination of Spring as Container and WebWork 2 as MVC framework
> is very powerful.
>
> What do you think about this ?
>
> Regards,
> Lars
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -- 
> 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 sponsored by: ApacheCon 2003, 16-19 November in Las Vegas.
Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java,
MySQL, WebDAV, and more! http://www.apachecon.com/
_______________________________________________ Springframework-developer
mailing list Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer