Help with putting transactions around webwork actions

[teknokrat]

Tried proxying the actions using TransactionProxyBean but this apparently creates singletons only and webwork actions cannot be singletons. Where do i go from here? has anyone successfully managed to do this. Is it perhaps better to create an Interceptor and proxy this?

thanks

[davison]

are you sure it's your web controllers that need to be transactional? Normally it would be your business objects whose methods are called from within your controllers (actions).

[teknokrat]

Correction, the actions are not webworks's but xwork's. This is the command framework we use for our business methods and has nothing to do with the web per se ( of course webwork uses them to produce our views )

We like xwork immensely, with chains, interceptors, result types etc, it makes wiring our app up so easy its actually fun again. with spring providing resource beans, transactions, hibernate templates etc it is a powerful combination. I will never work on a struts project ever again, it would be too painful after this

If only I could get spring's transaction proxy factory to not use singletons

[davison]

this thread in the AOP forum may explain it: http://forum.springframework.org/showthread.php?t=10632

Regards,

[Colin Sampaleanu]

Just use ProxyFactoryBean yourself, it's not actually that much more verbose, and you can still use parent/child definitions to save some of the typing.

The least verbose form when using the ProxyFactoryBean with a prototype is to just put the name of the prototype bean as the last name in the 'interceptorNames' list. The proxy factory will then just wrap it with a PrototypeTargetSource, without you having to do it.

Make sure you set the 'singleton' _property_ of the proxy factory bean to false, and the 'singleton' XML _attribute_ of the actual target bean to false.

[teknokrat]

Ok, thanks, I'lll give a go

first rate support guys!

[futang]

I'm having some trouble with proxied prototypes. First of all I do have it working correctly. I'm using this for xwork actions and an example of what I have is,

    <bean id="_action" class="com.opensymphony.xwork.ActionSupport" singleton="false"/>  
    
    <bean id="_actionProxy" class="org.springframework.aop.framework.ProxyFactoryBean">

        <property name="proxyTargetClass">
            <value>true</value>
        </property>

        <property name="singleton">
            <value>false</value>
        </property>
        
        <property name="interceptorNames">
            <list>
                <value>readOnlyActionTransactionInterceptor</value>
                <value>_action</value>
            </list>
        </property>
        
    </bean>

This works fine for the actual creation of proxied, prototype beans. However, I'm having a problem with this and Acegi. I've dug in a bit and Acegi's FilterToBeanProxy class uses the getBeansOfType(class, boolean, boolean) function. In Acegi's case the third parameter is true so FactoryBeans are included in the search. getBeansOfType basically iterates through all instances of FactoryBean calling getObjectType to see if it matches the class requested. The problem is getObjectType never calls refreshTarget so the call in getObjectType to getTargetSource().getTargetClass() throws a NullPointer.

Am I missing something here? Colin, you mention that the ProxyFactory automatically creates a PrototypeTargetSource but it looks to me like it's actually using a SingletonTargetSource that is just recreated by refreshTarget every time getObject is called.

Sorry for the long post, I'm just reaching the end of my wits. Thanks!

[Colin Sampaleanu]

I had prototypes on the brain, so in my previous message I typed PrototypeTargetSource instead of SingletonTargetSource. What I meant there was that a target source was created automatically for you, instead of needing to be created.

I do consider this a bug, to the extent that if you yourself feed the proxy factory a PrototypeTargetSource, the getObjectType() will work fine. In the case of just feeding the name as the last interceptor, what the code should do is itself create a PrototypeTargetSource from the beginning, or esle do it on demand.

I've filed a bug about this:
http://opensource.atlassian.com/proj...browse/SPR-434

In the meantime, what should work fine for you is to manually create a PrototypeTargetSource yourself, and feed it in as the targetseource property (don't forget to remove the bean name from the end of the list of interceptors). There's an example of configuring using this mechanism in this older thread:
http://forum.springframework.org/sho...targetsou rce

Alternately, you could also wrap with BeanNameAutoProxyCreator, as described in the manual, which will work fine for prototypes.

[futang]

Colin, thank you for such a thorough reply. I successfully worked around my previously problem, but I would like to discuss this issue a bit further.

I read your bug report and your suggestions makes sense, but I also don't think PrototypeTargetSource is the correct answer for the behavior we are looking for. PrototypeTargetSource creates a new object on every method call. This isn't the desired functionality for a command pattern based framework. I'm pretty sure what this usage requires is the lifecycle provided by the current implementation, a new SingletonTargetSource for every context.getBean request, but for the getObjectType to defer to BeanFactory.getBeanDefinition(beanName).getBeanCla ss().

What are you thoughts on this?

[Colin Sampaleanu]

You're right. I wasn't thinking too straight when I filed the bug report. There's no way you'd want to use PrototypeTargetSource. I've updated the bug report. I think Juergen is going to fix this for 1.1.2. I can also do it too if he doesn't have time...