Regression in RC2 or user error - please advise!

[sdwr98]

Hello,

I'm experiencing a problem in 2.0 RC2 that I did not have in RC1 or any previous releases. It's happening when I instantiate my transactional autoproxy wrapper. I'll attach my spring config and error logs, but in debugging, the key difference is this.

In RC1, when the DefaultAdvisorAutoProxyCreator is initialized, it finds and initializes all candidate advisors (code is in AbstractAdvisorAutoProxyCreator.setBeanFactory()). This code has the effect of initializing my Hibernate SessionFactoryBean before any other beans come along and need it.

In RC2, the code to pre-load candidate advisors has been removed. What this seems to produce is a circular dependency. When my application beans try to request the Hibernate SessionFactoryBean, it goes through a lot of dependencies, including the AutoProxyCreator, which depends on the TransactionSourceAdvisor, which depends on the TransactionInterceptor, which depends on the SessionFactoryBean. And so I get a NPE trying to instantiate the autoproxy creator.

I tried using the new tx:annotation-driven syntax, but it didn't work.

Any help figuring this out would be greatly appreciated!

Scott

[youngm]

I am having the exact same problem.

See my config and stacktrace below. If I remove any one of aspectj-autoproxy, annotation-driven or my custom Aspect then everything deploys fine. Otherwise I get the attached stacktrace. The below configuration appears to work just fine in RC1.

Config:

    <aop:aspectj-autoproxy/>

    <tx:annotation-driven/>

    <bean class="org.lds.stack.spring.serviceproxy.ServiceProxyAspect">
        <property name="jpaTemplate" ref="jpaTemplate"/>
    </bean>

    <!-- JPA EntityManagerFactory -->
    <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
        <property name="jpaVendorAdapter">
            <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
                <property name="showSql" value="true"/>
                <property name="generateDdl" value="false"/>
                <property name="database" value="ORACLE"/>
            </bean>
        </property>
        <property name="jpaPropertyMap">
            <map>
                <entry key="hibernate.cache.provider_class" value="org.hibernate.cache.NoCacheProvider"/>
            </map>
        </property>
        <property name="persistenceXmlLocation" value="classpath:/persistence.xml"/>
    </bean>

    <bean id="jpaTemplate" class="org.springframework.orm.jpa.JpaTemplate">
        <property name="entityManagerFactory" ref="entityManagerFactory"/>
    </bean>

    <bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
        <property name="entityManagerFactory" ref="entityManagerFactory"/>
    </bean>

[sdwr98]

Just an FYI - I've filed a bug for this problem: http://opensource.atlassian.com/proj...rowse/SPR-2278

[Costin Leau]

Thanks for reporting - it is important to get feedback on Release Candidates so that the final release is as compatible as possible.

[ThomasCorbin]

I got it when using a MethodInvokingFactoryBean to create a bean by running a method on another bean created by a MethodInvokingFactoryBean.

I change from using the MethodInvokingFactoryBean to using factory-bean and factory-method syntax, which I'd been meaning to for a while anyway. It was a blind shot in the dark, but it seems to work.

When I upgraded to spring 2.0 RC1 w/o changing any of my xml config files, everything worked. But I've been trying to use @Required, @Configurable, and @Transactional and have not had any success and much headaches.

I'm trying to swith from using the TransactionProxy stuff to @Transactional, but @Transactional doesn't seem to make my proxy implement all the interfaces the same way the TransactionProy stuff does, so I'm getting a LOT of property violation errors or casts.

And you *sure* don't want to accidentally use both at the same time!

My problems *seem* to stem from the fact that I haven't been as fanatical about using interfaces as Spring would seem to want me to be, but I am disappointed by how much effort it seems to take to switch. I had hoped that @Transactional et. al would be a big boon in ease of development, but @Configurable and @Required don't seem to work at all, and @Transactional is causing a lot of work, rather than making life easier. I'm bummed. I'm probably doing things wrong, but I'm bummed.

[Costin Leau]

My problems *seem* to stem from the fact that I haven't been as fanatical about using interfaces as Spring would seem to want me to be, but I am disappointed by how much effort it seems to take to switch. I had hoped that @Transactional et. al would be a big boon in ease of development, but @Configurable and @Required don't seem to work at all, and @Transactional is causing a lot of work, rather than making life easier. I'm bummed. I'm probably doing things wrong, but I'm bummed.

Interfaces are a good thing but Spring doesn't make them mandatory. With annotations, the 'context' is used a lot (i.e. where the annotation is applied, what does the enclosing class contains, etc.).
We're definitely trying to improve the user experience and feedback is always useful. Could you please start a separate thread about the annotations (along with your configuration) and explain what doesn't work and what would you'd like to see (you can actually raise the issues as enhancements on JIRA)?
Thanks.

[youngm]

One thing that would simplify annotating transactions when not using interfaces is to add the attribute "proxyTargetClass" to <tx:annotation-driven/>. Perhaps I'll make a JIRA issue for it.

Mike

[youngm]

So SPR-2278 has been fixed but I tried build 85 today and I am still experiencing a problem that appears related to this issue. Scott have you tried the latest nightly? I attached the exception I'm now getting with the same configuration file I posted above:

[youngm]

I've created another issue to hopefully get this issue solved for RC3: SPR-2350

[ehsavoie]

It's working with RC3 build 96.