[
https://issues.apache.org/jira/browse/WICKET-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Attila Király updated WICKET-3105:
----------------------------------
Attachment: wicket-ioc-1.4.x-branch-final-method-proxy.patch
Played around witch wicket and cglib and it seems that final methods are not
trully proxied. They are simply copied into the proxy class unmodified so they
work as the original. When they are called on the proxy there is no
interception before them but if they access an other, non-final method those
get intercepted. Because the final methods are not intercepted they access
fields on the proxy instance which is bad because those are very likely not
holding the same values as in the target bean.
After all I came up with a patch that makes some of the final methods usable
but it still leaves others unusable. Added a test assertion for the case that
is now working with the patch. The patch only modifies a few lines in
o.a.w.proxy.LazyInitProxyFactory.CGLibInterceptor.intercept(Object, Method,
Object[], MethodProxy) method. All tests pass with the patch (at least in
wicket-ioc, wicket-guice and wicket-spring I run only those).
Imho this proxying stuff is really unreliable with these quirks. Any thoughts
about incuding my SpringLocal variant?
> [wicket-ioc] Make it possible to use javassist instead of cglib for proxy
> generation
> ------------------------------------------------------------------------------------
>
> Key: WICKET-3105
> URL: https://issues.apache.org/jira/browse/WICKET-3105
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-spring
> Affects Versions: 1.4.12
> Environment: spring 3.0.4; servlet 2.5, 3.0
> Reporter: Attila Király
> Attachments: cglib-javassist-test.zip, SpringLocal2.java,
> wicket-ioc-1.4.x-branch-final-method-proxy.patch
>
>
> I got bitten with the cglib limitation of not handling final methods. This is
> a real pain because it can result in cryptic exceptions (like
> "IllegalArgumentException: Protected method: [a method name what I didn't
> call explicitly]"). I have checked wicket jira and I see others have problem
> with cglib too (like the need for a non-private no-arg constructor). While
> javassist can not solve all these problems, but at least a few of it (final
> method proxying works but no-arg constructors still needed).
> So I suggest to modify wicket-ioc to support both cglib and javassist. Like
> this (refactoring and extending o.a.w.proxy.LazyInitProxyFactory class):
> - make an IProxyFactory interface as common ancestor. Make 3 classes
> implementing it (JdkProxyFactory for interfaces, CglibProxyFactory to reflect
> current class proxying and JavassistProxyFactory as the new implementation)
> - make an IProxyInvocationHandler interface and an
> AbstractProxyInvocationHandler to hold common interface superclasses and
> methods (currently as protected static presented in LazyInitProxyFactory)
> - make the 3 invocation handlers implement AbstractProxyInvocationHandler (2
> are currently in LazyInitProxyFactory: JdkHandler and CGLibInterceptor and
> the 3rd would be the new JavassistMethodHandler)
> - make a new static classProxyFactory field in LazyInitProxyFactory that can
> be setted trough a public method. Its value should default to
> CglibProxyFactory (to be backward compatible).
> - modify LazyInitProxyFactory so it uses JdkProxyFactory for interfaces and
> the classProxyFactory for classes.
> - add javassist dependency to pom.xml as optional dependency
> (JavassistProxyFactory and JavassistMethodHandler should be outside of
> LazyInitProxyFactory class so they don't get loaded if they are not needed).
> In this way if someone wants to use javassist proxy instead of cglib only the
> followings are needed:
> - adding javassist to the dependent project's pom.
> - call LazyInitProxyFactory.setClassProxyFactory(new
> JavassistProxyFactory()); in the WebApplication init() method.
> I think these modifications could be made on the 1.4 branch too because they
> would not break the current public API of LazyInitProxyFactory (just add to
> it).
> Also could be made (but maybe these can't be done on the 1.4 branch because
> of compatibility):
> - pump cglib to 2.2 version from the current 2.1_3
> - factor cglib classes out from LazyInitProxyFactory and make cglib also an
> optional dependency
> I am willing to try to make a patch for this but first I would like to know
> the opinion of the wicket team about this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
