TransactionProxyFactoryBean results in StackOverflowError

Please help me.

I am using Spring 1.1 and JDK 1.5rc and each time I attempt to use TransactionProxyFactoryBean I get stuck in a recursive loop inside of CGLIB. Below you can find the relevant portion of my context definition file and the log file. I am using cglib-full-2.0.2.jar.

I did not have this problem when I was using Spring 1.0 and JDK 1.4.2 in a similar (but not identical) set up. Turning off optimize did not help.

Thanks in advance for any help you can provide.

Quote:

---

<bean id="extendableManagerImpl" class="com.bioarrayds.bioarraydb.logic.ExtendableM anagerBase">
<property name="extendableDAO"><ref local="extendableDAO"/></property>
<property name="nameValueTypeDAO"><ref local="nameValueTypeDAO"/></property>
</bean>
<bean id="extendableManager" class="org.springframework.transaction.interceptor .TransactionProxyFactoryBean">
<property name="transactionManager"><ref local="transactionManager"/></property>
<property name="target"><ref local="extendableManagerImpl"/></property>
<property name="transactionAttributes">
<props>
<prop key="*">PROPAGATION_REQUIRED</prop>
</props>
</property>
<property name="proxyTargetClass"><value>true</value></property>
<property name="optimize"><value>false</value></property>
</bean>


2004-09-17 17:44:42,180 DEBUG org.springframework.beans.factory.support.DefaultL istableBeanFactory - Retrieving depending beans for bean 'permissionDAO'
2004-09-17 17:44:42,180 DEBUG org.springframework.beans.factory.support.DefaultL istableBeanFactory - Applying DestructionAwareBeanPostProcessors to bean with name 'permissionDAO'
2004-09-17 17:44:42,180 ERROR org.springframework.web.context.ContextLoader - Context initialization failed
org.springframework.beans.factory.BeanCreationExce ption: Error creating bean with name 'extendableManager' defined in resource [/WEB-INF/application-context-generated.xml] of ServletContext: Initialization of bean failed; nested exception is java.lang.StackOverflowError: null
java.lang.StackOverflowError
at org.objectweb.asm.CodeAdapter.visitTableSwitchInsn (Unknown Source)
at net.sf.cglib.core.CodeEmitter.process_switch(CodeE mitter.java:605)
at net.sf.cglib.core.CodeEmitter.process_switch(CodeE mitter.java:583)
at net.sf.cglib.core.EmitUtils.string_switch_hash(Emi tUtils.java:268)
at net.sf.cglib.core.EmitUtils.string_switch(EmitUtil s.java:170)
at net.sf.cglib.core.EmitUtils.member_helper_type(Emi tUtils.java:810)
at net.sf.cglib.core.EmitUtils.access$900(EmitUtils.j ava:24)
at net.sf.cglib.core.EmitUtils$16.processCase(EmitUti ls.java:812)
at net.sf.cglib.core.EmitUtils$6.processCase(EmitUtil s.java:293)
at net.sf.cglib.core.CodeEmitter.process_switch(CodeE mitter.java:610)
at net.sf.cglib.core.CodeEmitter.process_switch(CodeE mitter.java:583)
at net.sf.cglib.core.EmitUtils.string_switch_hash(Emi tUtils.java:268)
at net.sf.cglib.core.EmitUtils.string_switch(EmitUtil s.java:170)
at net.sf.cglib.core.EmitUtils.member_helper_type(Emi tUtils.java:810)
at net.sf.cglib.core.EmitUtils.access$900(EmitUtils.j ava:24)
at net.sf.cglib.core.EmitUtils$16.processCase(EmitUti ls.java:812)
at net.sf.cglib.core.EmitUtils$6.processCase(EmitUtil s.java:293)
at net.sf.cglib.core.CodeEmitter.process_switch(CodeE mitter.java:610)
at net.sf.cglib.core.CodeEmitter.process_switch(CodeE mitter.java:583)
at net.sf.cglib.core.EmitUtils.string_switch_hash(Emi tUtils.java:268)
at net.sf.cglib.core.EmitUtils.string_switch(EmitUtil s.java:170)
at net.sf.cglib.core.EmitUtils.member_helper_type(Emi tUtils.java:810)
at net.sf.cglib.core.EmitUtils.access$900(EmitUtils.j ava:24)
at net.sf.cglib.core.EmitUtils$16.processCase(EmitUti ls.java:812)
at net.sf.cglib.core.EmitUtils$6.processCase(EmitUtil s.java:293)
at net.sf.cglib.core.CodeEmitter.process_switch(CodeE mitter.java:610)
at net.sf.cglib.core.CodeEmitter.process_switch(CodeE mitter.java:583)
at net.sf.cglib.core.EmitUtils.string_switch_hash(Emi tUtils.java:268)
at net.sf.cglib.core.EmitUtils.string_switch(EmitUtil s.java:170)
at net.sf.cglib.core.EmitUtils.member_helper_type(Emi tUtils.java:810)
at net.sf.cglib.core.EmitUtils.access$900(EmitUtils.j ava:24)
at net.sf.cglib.core.EmitUtils$16.processCase(EmitUti ls.java:812)
at net.sf.cglib.core.EmitUtils$6.processCase(EmitUtil s.java:293)
at net.sf.cglib.core.CodeEmitter.process_switch(CodeE mitter.java:610)
at net.sf.cglib.core.CodeEmitter.process_switch(CodeE mitter.java:583)
at net.sf.cglib.core.EmitUtils.string_switch_hash(Emi tUtils.java:268)
at net.sf.cglib.core.EmitUtils.string_switch(EmitUtil s.java:170)
at net.sf.cglib.core.EmitUtils.member_helper_type(Emi tUtils.java:810)

---

That looks to be an error with CGLIB under JDK 1.5, from the stack trace it seems to be repeating a lot of operations and then dying from lack of stack. I'm not sure if this is a problem with CGLIB, it could well be a problem with your JDK 1.5.

I don't have 1.5 installed here (using Mac OSX), but I will have access on Monday. In the meantime you can continue by using the JDK proxy. You will have to define an interface for you target bean and set this in TransactionProxyFactoryBean, then you need to set both optimize and proxyTargetClass to false.

I will look into this in more detail when I can get at a 1.5 machine.

Rob

My guess is that you would need to experiment with using CGLIB from their current CVS. This is based on a comment on Chris Nokleberg's blog

Quote:

---

JDK 1.5 is kind of a moving target, so it requires CGLIB and ASM from CVS.

---

http://sixlegs.com/blog/java/?year=2004&month=7&day=6

Just received a reply from Chris regarding this - he is as vexed as I am. I am going to put together a test case for this on Monday so I can demonstrate exactly what is going wrong - I am fairly certain this problem lies outside of Spring, but it would be nice to get it fixed so I'll do my best to help out the CGLIB guys.

Rob

Solman,

I am having a really hard time trying to reproduce this error. Is there any chance you can create a bug report in JIRA and post a simple set of example code that highlights the bug.

Rob

I haven't had an opportunity to find a minimal code set that replicates the bug. I just know that removing generic interfaces removes the bug.

Now that I know its necessary, I'll open up a report on JIRA and post a minimal set of replicating code. It may take a few days before I have the chance, however.

Solman,

That would be great - I'll get on it as soon as you make the JIRA post. I don't know if you can assign the issue to me automatically but if you can then do so.

Rob