[jira] Issue Comment Edited: (WICKET-3105) [wicket-ioc] Make it possible to use javassist instead of cglib for proxy generation

["Attila Király (JIRA)" <ji...@apache.org>]

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

Attila Király edited comment on WICKET-3105 at 10/14/10 3:40 AM:
-----------------------------------------------------------------

As a side note I would like to share an other solution for spring - wicket integration I came up with yesterday.

It is different to the current wicket offering because
- it does not need a ComponentInjector (like SpringComponentInjector) or an annotation (@SpringBean) to listen and check for every instance fields so in theory it could be faster
- it does not uses generated proxies (jdk, cglib or javassist) but supports serialization and lazy loading (detach, attach) and does not suffer any of the generated proxy shortcommings (need for no-private no-arg constructor, lost annotations).

It's a hand written general proxy (we could call it Pop - Plain Old Proxy) inspired by ThreadLocal and SpringBean so I named it SpringLocal.

Declaration example:
private final SpringLocal<AuthenticationManager> authenticationManager = SpringLocal.make(AuthenticationManager.class, "authenticationManager");
private final SpringLocal<AbstractRememberMeServices> rememberMeServices = SpringLocal.make(AbstractRememberMeServices.class);

Access example:
authenticationManager.get().authenticate(token);
AbstractRememberMeServices rememberMeServices = rememberMeServices.get();

It could be included into wicket-spring if needed.

      was (Author: akiraly):
    As a side note I would like to share an other solution for spring - wicket integration I came up with yesterday.

It is different to the current wicket offering because
- it does not need a ComponentInjector (like SpringComponentInjector) or an annotation (@SpringBean) to listen and check for every instance fields so in theory it could be faster
- it does not uses generated proxies (jdk, cglib or javassist) but supports serialization and lazy loading (detach, attach) and does not suffer any of the generated proxy shortcommings (need for no-private no-arg constructor, lost annotations).

It's a hand written general proxy (we could call it Pop - Plain Old Proxy) inspired by ThreadLocal and SpringBean so I named it SpringLocal.

Declaration example:
private final SpringLocal&lt;AuthenticationManager&gt; authenticationManager = SpringLocal.make(AuthenticationManager.class, "authenticationManager");
private final SpringLocal&lt;AbstractRememberMeServices&gt; rememberMeServices = SpringLocal.make(AbstractRememberMeServices.class);

Access example:
authenticationManager.get().authenticate(token);
AbstractRememberMeServices rememberMeServices = rememberMeServices.get();

It could be included into wicket-spring if needed.
  
> [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, SpringLocal.java
>
>
> 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.