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

[Rob H. <ro...@ca...>]

Sorry, yes you are right. And yes there is some potential for funny 
behaviour. Spring 1.2 shows this less than 1.1, but a full fix requires 
a mod to CGLIB which the CGLIB are working on now.

Rob

Colin Sampaleanu wrote:

> 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
>>>
>>>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>