Re: [Springframework-developer] Issue SPR-285 - proxying with no-arg constructor in CGLIB

[Colin S. <col...@ex...>]

Do you not mean that the constructor on the target bean will be fired 
when the target bean is actually created? This may be different from 
when the proxy is created obviously. Then the constructor gets fired 
again when the proxy is created, which is a subclass of the target 
class, right? So there is potential for weird behaviour when there are 
none idempotent constructors, I presume?


Rob Harrop wrote:

> Colin,
>
> The constructor on the target bean will be fired when the proxy is 
> created with the arguments supplied in the <constructor-arg> tags. 
> When the proxy is created the constructor is called again, and 
> currently will in certain circumstances override any state set by the 
> first call of the constructor. This is behavior is covered under 
> another issue and teh CGLIB guys are looking at a fix to allow us to 
> avoid redirecting calls during proxy creation so that no state gets 
> overwritten.
>
> The best way forward as I see it is to add 
> setConstructorArguments(Object[]) and 
> setConstructorArgumentTypes(Class[]) to ProxyFactoryBean. The user can 
> specify both if he chooses otherwise he just needs to specify a value 
> for the first and the Spring will attempt to determine the types (very 
> loosely, using the types of the Objects passed in ).
>
> Rob
>
> Colin Sampaleanu wrote:
>
>> The main issue I see, unless I'm missing something, with passing in 
>> constructor args to the ProxyFactoryBean is having decent type 
>> conversion. When you pass in properties or normal constructor-args to 
>> a bean, you get decent PropertyEditor based type conversion 
>> happening. The code would need to do something similar to 
>> ArgumentConvertingMethodInvoker and its superclass MethodIInvoker. 
>> Now the latter are kind of stupid in that they get confused when 
>> there are multiple matching methods. If the ProxyFactoryBean variant 
>> passed along as the second param a Class[], then there's no 
>> ambiguity. It's also more of a pain to use, and maybe should be 
>> possible to pass in a null array, in which case the code will do its 
>> best, which might be enough when there're only one or two 
>> non-ambiguous constructors.
>>
>> But what happens with the constructors from the target bean? They 
>> just get ignored?
>>
>>
>> Rob Harrop wrote:
>>
>>> All,
>>>
>>> We really need to come to a desicion of how this should be 
>>> implemented if I am to get a fix done in time for 1.1.3. Currently I 
>>> see two ways to solve the problem:
>>>
>>> 1. Add setConstructorArgs(Object[], Class[]) to ProxyFactoryBean
>>> 2. Attempt to locate the <constructor-arg> definitions of the target 
>>> bean, although I think this involves iterating over the bean 
>>> definitions attempting to match to the target. Also when using 
>>> anything but a SingletonTargetSource the match might not succeed.
>>>
>>> I am taking a break this week but I will be around for discussion on 
>>> this - just won't be starting it until Monday.
>>>
>>> Rob
>>