|
From: Rob H. <ro...@ca...> - 2005-02-03 22:02:34
|
I can check for the existence of the new method and if it is there, use it to fix the bug otherwise just ignore it. I can perform the check just once when the first proxy is created and then cache the results for later - it shouldn't take too long to do. Rob Juergen Hoeller wrote: >IMO, Spring 1.1.5's version of Cglib2AopProxy needs be able to run on CGLIB >2.0.2, as this is what most people will have on their class path (from >previous Spring versions, but also from Hibernate). > >I guess it depends on whether it's feasible to put corresponding CGLIB >2.0/2.1 checks in Cglib2AopProxy's code. It would be great if that was >possible without too much effort. In that case, shipping with CGLIB 2.1 is >not a problem. > >However, if such checks turn out to be awkward, I vote for rolling back >Cglib2AopProxy to CGLIB 2.0.2 compatibility - for Spring 1.1.5. We should >defer the CGLIB 2.1 dependency till Spring 1.2 in that case (which will >follow up soon anyway). > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of Rob Harrop >Sent: Thursday, February 03, 2005 10:43 PM >To: spr...@li... >Subject: Re: [Springframework-developer] Proxying Classes without a >Default Constructor > > >Juozas assures me that 2.1 will be final next week so there should be no >problems on that front. Cglib2AopProxy won't run on 1.1.5 without CGLIB >2.1 since I had to modify the code to take advantage of new features. I >can switch the class back if you'd prefer, or I can probably put some >detection logic in there to test for 2.1 or 2.0.2. That way the code >should run on 2.0.2, but one test won't pass - the one that is fixed by >the new feature. > >Rob > >Juergen Hoeller wrote: > > > >>OK, then I vote for closing it as "won't fix" :-) >> >>Regarding CGLIB 2.1: Suppressing constructor calls to bean property setters >>is fine, I guess, as this is a pretty common case even for JavaBeans with >>default constructors. CGLIB 2.1 should become final within the next 3 >> >> >weeks, > > >>though; we definitely shouldn't delay Spring 1.1.5 because of it. >> >>Does Cglib2AopProxy still run on CGLIB 2.0.2, or do we have some central >>dependency on CGLIB 2.1? Would Spring 1.1.5 built against CGLIB 2.1 still >>run with CGLIB 2.0.2 on the class path? Else, we would force 1.1.5 users to >>upgrade their CGLIB version too, which we should avoid... >> >>BTW, I don't mind exposing the constructor-arg functionality on the >> >> >internal > > >>Cglib2AopProxy itself, as we already do. I'd just prefer to not expose it >> >> >on > > >>the user-visible ProxyFactory/ProxyFactoryBean. >> >>Juergen >> >> >>-----Original Message----- >>From: spr...@li... >>[mailto:spr...@li...]On Behalf >>Of Rob Harrop >>Sent: Thursday, February 03, 2005 10:05 PM >>To: spr...@li... >>Subject: Re: [Springframework-developer] Proxying Classes without a >>Default Constructor >> >> >>Actually, I agree with this, I just want to get this issue fixed or >>closed - I feel guilty every time I look at JIRA :). The upgrade to >>2.1dev was to fix the problem related to side effects of calling >>constructors that initialized state for a 2nd time during proxy >>creation. The creation of a proxy with CGLIB will no longer reset any >>bean state if the constructor has calls to initialize the state. >> >>Juergen Hoeller wrote: >> >> >> >> >> >>>Rob, everybody, >>> >>>Some thoughts on the level of our CGLIB support. I have hinted at this >>>before; I guess it is the time to seriously discuss desirable and >>>undesirable features now. >>> >>>I'm inclined to argue that we shouldn't support proxying of classes >>> >>> >without > > >>>default constructor in the first place. It feels so wrong to have to >>> >>> >>> >>> >>specify >> >> >> >> >>>constructor args on a ProxyFactoryBean... and to actually execute the full >>>constructor of the target class just for the proxy instance, with those >>>problems of suppressing method calls in the constructor (to avoid side >>>effects) etc. >>> >>>For my taste, this goes too far. CGLIB proxies are already debatable with >>>default constructors that perform initialization work, and simply feel >>> >>> >like > > >>>a big hack when used with a non-default constructor. IMO, the proxy-based >>>AOP approach is not recommendable for such needs: Go for full-blown >>> >>> >AspectJ > > >>>or add the additional behavior in a more traditional way (wrapping, >>>subclassing, whatever). >>> >>>I'd like to hear opinions on the value of proxying classes with >>> >>> >non-default > > >>>constructors. I currently prefer to avoid that feature in the first place, >>>but I'm open to getting convinced otherwise. >>> >>>Juergen >>> >>> >>>P.S.: I suppose that the CGLIB upgrade to 2.1-dev was necessary for this? >>>Does this mean that we could stick with CGLIB 2.0.2 (for Spring 1.1.5) if >>> >>> >>> >>> >>we >> >> >> >> >>>avoid supporting non-default constructors for proxies? >>> >>> >>>-----Original Message----- >>>From: spr...@li... >>>[mailto:spr...@li...]On Behalf >>>Of Rob Harrop >>>Sent: Thursday, February 03, 2005 9:31 PM >>>To: spr...@li... >>>Subject: [Springframework-developer] Proxying Classes without a Default >>>Constructor >>> >>> >>>All, >>> >>>I'm going to raise this issue again in the hope that we can reach a >>>consensus before 1.1.5. I have modified Cglib2AopProxy to support >>>classes without a default constructor, we just need to make this >>>functionality available in a configurable manner. Ideally this would be >>>done with setConstructorArgs(Object[]) and >>>setConstructorArgTypes(Class[]) methods on ProxyFactoryBean. >>> >>>Rob >>> >>> >>>------------------------------------------------------- >>>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >>>Tool for open source databases. Create drag-&-drop reports. Save time >>>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >>>Download a FREE copy at http://www.intelliview.com/go/osdn_nl >>>_______________________________________________ >>>Springframework-developer mailing list >>>Spr...@li... >>>https://lists.sourceforge.net/lists/listinfo/springframework-developer >>> >>> >>> >>>------------------------------------------------------- >>>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >>>Tool for open source databases. Create drag-&-drop reports. Save time >>>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >>>Download a FREE copy at http://www.intelliview.com/go/osdn_nl >>>_______________________________________________ >>>Springframework-developer mailing list >>>Spr...@li... >>>https://lists.sourceforge.net/lists/listinfo/springframework-developer >>> >>> >>> >>> >>> >>> >>> >>> >>------------------------------------------------------- >>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >>Tool for open source databases. Create drag-&-drop reports. Save time >>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >>Download a FREE copy at http://www.intelliview.com/go/osdn_nl >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >>https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >>Tool for open source databases. Create drag-&-drop reports. Save time >>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >>Download a FREE copy at http://www.intelliview.com/go/osdn_nl >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >>https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> >> >> >> > > >------------------------------------------------------- >This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >Tool for open source databases. Create drag-&-drop reports. Save time >by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >Download a FREE copy at http://www.intelliview.com/go/osdn_nl >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >Tool for open source databases. Create drag-&-drop reports. Save time >by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >Download a FREE copy at http://www.intelliview.com/go/osdn_nl >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > |