Re: [Springframework-developer] Extending Spring AOP

[Colin S. <col...@ex...>]

One concern with AspectWerkz is the LGPL license. While Hibernate is 
also LGPL licensed, it is less a core part of Spring than the AOP stuff 
is. Now both Hibernate and AspectWerkz have a 'clarifying' statement 
about their interpretation of the LGPL:
  http://aspectwerkz.codehaus.org/license.html
such that there is less ambiguity (in theory) about linkage to it, but I 
would be a bit reticent to have the main (non-proxy) AOP implementation 
in Spring be based on AspectWerkz because of concerns that Spring using 
organizations would have about LGPL. Whatever it's intentions, the LGPL 
is so badly worded that a number of companies will simply not use any 
libraries which are LGPL licensed...

Colin


Rob Harrop wrote:

> AspectWerkz proxy is actually quite performant and provides specific 
> optimizations for before and after advice. It may be worthwhile 
> putting together an AWProxy implementation of proxy factory since it 
> can be done quite easily. The benefit of using Janino is that we have 
> full control over all the code that is created making it much easier 
> to work around any problems we may encounter. You can find performance 
> figures of AWProxy compared to Spring proxies at 
> http://blogs.codehaus.org/people/jboner/archives/000914_awproxy_proxy_on_steroids.html 
> although you can take off between 50%-75% based on tests I have made 
> with optimized proxies.
>
> The CGLIB implementation is becoming quite hard to maintain and it is 
> much more complicated to produce advice specific bytecode with CGLIB 
> than it will be with Janino. Since AWProxy support should be trivial 
> it is entirely possible that we can support both.
>
> Rob
>
> P.S. Is anyone else having problems with the mailing list? I got 
> unsubscribed somehow :(
>
> Dmitriy Kopylenko wrote:
>
>> Thanks Rod.
>>
>> Yeah, AspectWerkz proxy could be a viable option if it delivers 
>> significantly better performance than standard JDK proxy
>>
>>
>> Colin Sampaleanu wrote:
>>
>>> I guess anothr option is using the new AspectWerkz proxy 
>>> implementation...
>>>
>>>
>>> Rod Johnson wrote:
>>>
>>>> 1. Performance (marketing more than reality, but marketing can't be 
>>>> ignored)
>>>> 2. Problems with the CGLIB implementation. Another approach may 
>>>> well deliver better results.
>>>> 3. Potential to add additional features, if the approach works out 
>>>> well.
>>>>
>>>> It should be largely transparent to the developer view. I 
>>>> introduced the AopProxyFactory interface for that reason.
>>>>
>>>> Dmitriy Kopylenko wrote:
>>>>
>>>>> Rob/Rod,
>>>>>
>>>>> can you please summarize the reasons to create another proxy 
>>>>> implementation strategy?
>>>>>
>>>>> Thanks,
>>>>> Dmitriy.
>>>>>
>>>>> Rob Harrop wrote:
>>>>>
>>>>>> I agree, I'll put together a quick prototype either today or next 
>>>>>> week to see how a specificically created proxy will perform.
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>> Rod Johnson wrote:
>>>>>>
>>>>>>> Rob
>>>>>>>
>>>>>>> I would favour the Java code-based approach, using Velocity. I 
>>>>>>> think that should deliver extremely good performance, and would 
>>>>>>> rather we don't commit to maintaining a byte code approach.
>>>>>>>
>>>>>>> I don't believe there is any problem using code generation with 
>>>>>>> our API. Indeed, I always meant to implement it, but performance 
>>>>>>> optimization of the AOP framework has never been of any 
>>>>>>> significance in practice. Only for marketing, as has been 
>>>>>>> apparent recently :-)
>>>>>>>
>>>>>>> A Java based approach should definitely allow significant 
>>>>>>> optimization, and would hopefully be simpler than the CGLIB 
>>>>>>> approach and more maintainable. So there would be a real 
>>>>>>> advantage, besides performance. There should be a particular 
>>>>>>> optimization for methods with only before or after advice, 
>>>>>>> skipping the present use of an interceptor to wrap them. The
>>>>>>>
>>>>>>> I would recommend hand-authoring a Java class, and benchmarking, 
>>>>>>> to see exactly what the gains are, before putting a lot of 
>>>>>>> effort into the approach. (But I'm sure they'll be large.) But I 
>>>>>>> think this is definitely good stuff!
>>>>>>>
>>>>>>> Rgds
>>>>>>> Rod
>>>>>>>
>>>>>>> Rob Harrop wrote:
>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>> I am planning to add to an additional proxy implementation to 
>>>>>>>> Spring to solve some of the problems we are experiencing with 
>>>>>>>> other approaches and to allow for additional optimizations and 
>>>>>>>> advice types to be added in the most efficient way.
>>>>>>>>
>>>>>>>> Currently, I'm looking at two separate approaches - Java-based 
>>>>>>>> using Janino and Bytecode-based using SERP. The Java-based 
>>>>>>>> approach should be quite simple to create and could be coupled 
>>>>>>>> with Velocity to externalize much of the boilerplate code 
>>>>>>>> needed for the creation of proxy classes. Alternatively we 
>>>>>>>> could add a simple abstraction layer on top of Janino, a la 
>>>>>>>> .NET CodeDOM (good idea James). The bytecode approach is much 
>>>>>>>> more complex and will be harder to debug but it would probably 
>>>>>>>> allow for absolute raw performance.
>>>>>>>>
>>>>>>>> I am comfortable with either approach although I think that 
>>>>>>>> Janino would be ideal for our purposes.
>>>>>>>>
>>>>>>>> Your thoughts?
>>>>>>>>
>>>>>>>> Rob
>>>>>>>