Re: [Springframework-developer] Extending Spring AOP

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

That makes sense...

Rob Harrop wrote:

> I wasn't planning on having the AspectWerks proxy being the main 
> implementation. My plan was to keep the JDK proxy as the main 
> implementation because of its simplicity, replace the CGLIB proxy with 
> Janino as the second proxy of choice and then provide AspectWerkz as a 
> low maintenance, high performance choice for the core advice types 
> that we have now. I think that your concerns about LGPL fit with this 
> vision as well.
>
> Rob
>
> Colin Sampaleanu wrote:
>
>> 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
>>>>>>>>>