If I had to venture a 2 second guess, I'd say you are using constructor injection for the bean in question and you have a circular reference. A circular reference is when BeanA has BeanB as a dependency and BeanB has BeanA as a dependency. What happens is the ColdSpring elf tries to create BeanA and realizes it needs BeanB to complete the work. So the ColdSpring elf goes off to make BeanB, so it can complete the original request for BeanA. As it is in process creating BeanB, it realizes it needs a BeanA to complete the work, so the ColdSpring elf goes off to make a Bean A so it can complete the request for BeanB so it can complete the original request for BeanA. However, as it is creating the BeanA for the BeanB for the BeanA, the ColdSpring elf realizes it needs a BeanB......
Get the picture? The solution is to change the dependency method to setter injection. This means change your constructor-arg to a property node in the ColdSpring.xml and make a get/set function for the bean. There. Problem Solved. Report back any issues you have. DW On Wed, Mar 11, 2009 at 11:07 AM, George <[email protected]> wrote: > > Okay - so this may be more of a ColdSpring question than a Model-Glue > question but I thought I would check here first to see if anyone had > any ideas. > > I've been working on building a fairly large Model-Glue application > and it's been up and running for going on 4 months. Yesterday I was > working on some of the planned enhancements when I ran into a 500 > ROOT CAUSE: java.lang.StackOverflowError problem. I've tracked it > down to one instance of adding one referenced bean onto one of my > service instances. I can comment out the bean and everything > compiles. I can change it to one of my DAO beans and it works, I > change it to another of my service beans and it causes the > StackOverflowError again. I have moved some of the ColdSpring.xml out > to includes to reduce the file size and that has had no effect. I > updated to 1.2 and had no change either. > > I've seen some minor changes in the rest of the error stack when I > change up the service I'm including, but it's more often than not this > as the next couple lines: > > at coldfusion.runtime.LocalScope.bindInternal(LocalScope.java:373) > at coldfusion.runtime.LocalScope.bindInternal(LocalScope.java:387) > at > cfAbstractBeanFactory2ecfc1246833417$funcRESOLVEBEANNAME.runFunction(C: > \xxx\xxxx\xxxx\coldspring\beans\AbstractBeanFactory.cfc:193) > at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:418) > at coldfusion.filter.SilentFilter.invoke(SilentFilter.java:47) > at coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke > (UDFMethod.java:360) > at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke > (UDFMethod.java:324) > at coldfusion.filter.FunctionAccessFilter.invoke > (FunctionAccessFilter.java:59) > at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:277) > at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:192) > at coldfusion.runtime.CfJspPage._invokeUDF(CfJspPage.java:2471) > > followed by a repeating of the above with several other calls to the > cfAbstractBeanFactory instance. > > I know I'm not providing much, but I'm absolutely stumped as to what > can be causing the problem. The bean I am adding that causes the > error is also used as a ref bean on another bean without causing the > problem. Any ideas that I could poke around at would be much > appreciated! > > George > > > -- “Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew.” Guillaume Apollinaire quotes --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "model-glue" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/model-glue?hl=en For more about Model-Glue, check http://www.model-glue.com . -~----------~----~----~----~------~----~------~--~---
