StackOverflowError when expression calls method which is a Collection of itself [SPR-9735]

[spring-projects-issues]

Marc Wielansky opened SPR-9735 and commented

StackOverflowError results from ReflectiveMethodExecutor.execute(EvaluationContext, Object, Object...) line: 69 when returned object is a collection of itself.

Example:

expression: "manager.getItem()"
method: public Item getItem() { return item; }
class: public class Item implements List<Item> - this object has properties, but also is a list of items of the same type

---

Affects: 3.1.1, 3.2.8

Attachments:

• Item.java (2.30 kB)
• ReflectiveMethodExecutorTest.java (878 bytes)

Issue Links:

• util:map does not recognize the attribute of value-type [SPR-10994] #15622 util:map does not recognize the attribute of value-type

[spring-projects-issues]

Chris Beams commented

Andy Clement, your thoughts?

[spring-projects-issues]

Andy Clement commented

Yes, I can imagine this is an issue. IIRC, there isn't anything coded in there to avoid a recursive case.

[spring-projects-issues]

Andy Clement commented

I was just trying to craft a testcase for this problem but I'm having trouble. If anyone has one, let me know. I tried creating the supplied expression, method and class but it doesn't stack overflow.

[spring-projects-issues]

Andy Clement commented

I see you attached some source files, thanks for that. I am trying to build them and it just runs for me printing 'child1'. Does that main method stack overflow for you? What Java level are you on? I've tried Java8 with current spring master and also Java6/7 with Spring 3.1.1 release.

[spring-projects-issues]

Marc Wielansky commented

I'm on Java 7 [1.7.0_65-b17] with Spring 3.2.8.

Per your suggestion, I also tested with Spring 4.x and it works there without any issues - which I guess makes this a lower priority item if not resolved. Thanks for your help.

[spring-projects-issues]

Andy Clement commented

Thanks for that info. I can confirm it does fail on 3.2.8.RELEASE:

at org.springframework.core.convert.AbstractDescriptor.getElementTypeDescriptor(AbstractDescriptor.java:47)
at org.springframework.core.convert.TypeDescriptor.<init>(TypeDescriptor.java:547)
at org.springframework.core.convert.AbstractDescriptor.getElementTypeDescriptor(AbstractDescriptor.java:47)
at org.springframework.core.convert.TypeDescriptor.<init>(TypeDescriptor.java:547)
at org.springframework.core.convert.AbstractDescriptor.getElementTypeDescriptor(AbstractDescriptor.java:47)
at org.springframework.core.convert.TypeDescriptor.<init>(TypeDescriptor.java:547)
at org.springframework.core.convert.AbstractDescriptor.getElementTypeDescriptor(AbstractDescriptor.java:47)
at org.springframework.core.convert.TypeDescriptor.<init>(TypeDescriptor.java:547)

TypeDescriptor in core seems to have gone through some radical changes in the 4.x line compared to 3.x which probably explains it no longer happening - not quite sure which change addressed it though.

[spring-projects-issues]

Juergen Hoeller commented

Alright, I have another 3.2.x-only issue on my plate still, so I'll give this one a try as well. If a reasonably simple fix is possible in 3.2.x's TypeDescriptor architecture, I'll roll it into 3.2.12 - to be released towards the end of this week.

That said, I'd generally recommend an upgrade to Spring Framework 4.1.x. Many subtle issues have been fixed there beyond the 3.2.x line in the meantime, and after 3.2.12, we'll be very conservative about backports.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

I'm afraid we'll have to leave this as a known issue in the 3.2.x line since it turns out to be hard to fix within 3.2.x's TypeDescriptor architecture... without risking a side effect on other scenarios, which is hard to justify at this late stage of the branch.

Note that the 4.x line has a significantly revised type definition and type matching architecture and is generally preferable for any applications with non-trivial use of generics.

Juergen