Unfortunately, no. I’ll bitch some
more :)
-----Original Message-----
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew E. Porter
Sent: Tuesday, November 04, 2003
8:54 AM
To:
[EMAIL PROTECTED]
Subject: Re: [OS-webwork] Anyone
working on Spring Framework Integration?
Is the
webwork-ext project setup? This seems like a perfect candidate (if this is open
source).
Cheers,
matthew
On Nov 4, 2003, at 8:18 AM, Cameron Braid wrote:
Is your implementation of this code closed source, or
are you able to share it ?
I would be keen to have a look.
Cheers,
Cameron
Rob Rudin wrote:
Cameron
- I'm using the latter approach, although this is with
1.3, and I've unfortunately been lazy and haven't
looked into
WW2 yet. But I assume an ActionInvocation is
similar to an
Action? In 1.3, I have a
"SpringActionFactoryProxy" that checks
to see if the Action is defined in the Spring
configuration. If
it doesn't find the Action, then the
JavaActionFactory
eventually loads the Action (which is good so that
you don't
have to configure Action's that don't need
resources from the
Spring container). I also use the Hibernate
interceptors, and
everything works well, and the Webwork files
aren't polluted
with any Spring stuff. I think this sounds similar
to what you
suggested below, so I'd say go for the latter.
Rob
---- On Sat, 01 Nov 2003, Cameron Braid ([EMAIL PROTECTED]/color>)
wrote:
Is anyone
working on integration between Xwork and the Spring
Framework.
I have
managed to create a webwork interceptor that allows a
xwork
action to make
use of any spring bean by creating a simple
mapping.
However, I
would like a better soloution that uses spring as
the action
facory.. And
I would like to do this without duplication of
configuration in both xwork.xml and
applicationContext.xml
One main reason that I want to use spring is to
take advantage
of its
AOP
framework, and most specifically the Hibernate Transaction
Interceptor.
Therefore I
would like to declare the transactional attributes
for the
action
methods within spring, with a refrence to the xwork
action.
I woule like
to still use WebWork's interceptors as normal -
timing,
logging,
params, chain, etc.. because they have different
semantics to
spring.
One way that I think this is possible is to create
:
Spring Objects :
a spring action factory bean, configured with the
action
namespace
and name and
the transactional attributes
this factory would lookup the action config for
the
classname
and
construct
the action, wrap it in a proxy, attaching the
interceptors.
WebWork
Objects
SpringServletDispatcher - to call
ActionProxyFactory.setFactory(new
SpringActionProxyFactory())
SpringActionProxyFactory - to override
createActionInvocation
to use
a
SpringActionInvocation
SpringActionInvocation - to override createAction
- to
delegate to
WebApplicationContextUtils.getWebApplicationContext(servletContext).getBean(beanName)
to use the
factory within spring to contruct this action.
This way the xwork.xml file remains untouched and
all that is
needed is
a bean entry
in applicationContext.xml that defines each
action's
transactional
attributes.
Something like :
<bean
id="defaultActionTransactionAttributes"
class="com.datacodex.spring.beans.PropertiesFactoryBean">
<property name="properties">
<props>
<prop
key="execute">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
<bean id="admin.SpringAction"
class="WebworkActionFactoryBean">
<property
name="action"><value>/admin/SpringAction</value></property>
<property
name="transactionManager"><ref
local="transactionManager"/></property>
<property
name="transactionAttributes"><ref
local="defaultActionTransactionAttributes"/></property>
</bean>
I am open to suggestions for other ways to do
this.
Anyone have any thoughts / ideas ?
Cameron
--
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/color>]
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback
Program.
Does SourceForge.net help you be more productive?
Does it
help you create better code? SHARE THE LOVE, and
help us
help
YOU! Click
Here: http://sourceforge.net/donate//color>
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]/color>
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork/color>
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback
Program.
Does SourceForge.net help you be more productive?
Does it
help you create better code? SHARE THE LOVE, and
help us help
YOU! Click Here: http://sourceforge.net/donate//color>
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]/color>
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork/color>
--
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/color>]
------------------------------------------------------- This SF.net email is
sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more
productive? Does it help you create better code? SHARE THE LOVE, and help us
help YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________ Opensymphony-webwork mailing
list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork