Re: [Springframework-developer] Proxying Classes without a Default Constructor

[Juergen H. <ju...@in...>]

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