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

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

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