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