[ 
https://issues.apache.org/jira/browse/WICKET-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921454#action_12921454
 ] 

Igor Vaynberg commented on WICKET-3105:
---------------------------------------

thats what i thought. final methods cannot be proxied.

i dont think im going to apply your patch that makes the method accessible, 
since doing so makes it even easier to get an unintended consequence - such as 
being able to call a method that uses fields of the proxy subclass instead of 
the proxied object. i would rather the code failed.

as far as SpringLocal, i do not see much point to it. the main advantage of 
proxies is that it makes code like this possible:

{code}
class mypage extends webpage {
  @SpringBean Service service;
  
  public mypage() {
     add(new datatable(..., new dataprovider(service))); <== notice we can pass 
a reference of injected service into other objects
  }
}
{code}

with spring local i would have to pass the spring local itself into other 
objects, but at that point i might as well just have my application object be 
injected with the service and use lookups like this in both page and 
dataprovider, seems easier:
{code}MyApplication.get().getService();{code}

im going to close the issue, feel free to reopen it if you have new ideas on 
how to improve the current implementation.

> [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.

Reply via email to