Menu
▾
▴
springframework-developer
|
From: Rob H. <ro...@ca...> - 2004-11-23 10:19:22
|
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 |
|
From: Colin S. <col...@ex...> - 2004-11-30 15:02:50
|
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 |
|
From: Rob H. <ro...@ca...> - 2004-11-30 15:11:45
|
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 > > |
|
From: Colin S. <col...@ex...> - 2004-11-30 15:43:32
|
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 >> |
|
From: Rob H. <ro...@ca...> - 2004-11-30 15:47:53
|
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 > > |
