Brian
On 4/10/06, Chris Scott
<[EMAIL PROTECTED]> wrote:
Hey Brian, all of that code will be removed from getBeanInstance() in BeanDefinition.cfc. What the current implementation of factory-bean is doing is actually happening in the wrong place, and it's causing a few issues. I am working on a new system of creating factory beans, that will cause the entire bean construction to happen in a different cycle. It's kind of hard to picture, we already have the system in place to build beans correctly (as you see when you use a non-factory bean) what we are going to do is extend BeanDefinition for a new type, that will be able to trick the bean creation process into building factory beans in the way the user intends.So short answer, I'm working on it!Thanks, ChrisOn Apr 10, 2006, at 4:39 PM, Brian Kotek wrote:I think that the problem might be in the getBeanInstance() method of the BeanDefinition. This method is called from within the constructBean() method of DefaultXMLBeanFactory. In getBeanInstance(), there is logic that checks to see if the current bean definition is a factory bean, and if so, it loops through the arguments and calls the factory method, adding an argument to the factory method call for each argument in the constructor arguments defined for the bean.
The problem appears to be twofold, first, this inclusion of arguments to the factory method doesn't appear to be recursive, ie if you passed a struct of a struct it would just pass that whole thing as an argument to the factory method. The second problem is related, in that since the arguments are not checked recursively, any BeanReference values in the arguments are just passed on into the factory method and are never translated into actual references to the beans they are placeholding for.
I'm trying to find where non-factory BeanReferences are translated, and I think it happens in constructComplexProperty() within the DefaultXMLBeanFactory.
I'm not entirely sure what the fix is, but it seems like it will require either adding recursion to the arguments as they are passed into the factory method, or possibly "transforming" the BeanReferences into actual bean references *before* the factory method stuff is handled.
Any ideas? I just wanted to get some feedback to see if I am on the right track before I try to write some sort of fix only to find out that I was missing something that would have made the fix easier.
Thanks,
BrianOn 4/10/06, Brian Kotek < [EMAIL PROTECTED]> wrote:Just a follow up on this, I've got a very small app that reproduces this problem. It appears to only affect factory method calls, if you pass a ref-bean as a struct value to a non-factory method bean, it does pass the a reference to the actual bean bean and not the BeanReference. Now I'll try to look at the CS code to see if I can fix this, but if someone with more familiarity with the code has an idea of what might be the cause, by all means fire away. Thanks.On 4/6/06, Brian Kotek < [EMAIL PROTECTED]> wrote:OK one more potential issue that I thought I'd bring up. I've got this in my XML:
<bean id="userDSN" factory-bean="DSNFactory" factory-method="newDSN">
<constructor-arg name="parameters">
<map>
<entry key="configManager">
<ref bean="configManager" />
</entry>
</map>
</constructor-arg>
</bean>
Which should, if I understand it, pass a structure named parameters with key called "configManager" and the value should be a reference to the already created bean named "configManager". However, when I run this, I get a struct named "parameters" with a key called "configManager", but the value is an object of type " coldspring.beans.BeanReference", not of type "configManager". I'll look into it further and post again if I come up with any ideas/answers. Thanks.
