Re: [Springframework-developer] Extending Spring AOP

[Rod J. <ro...@in...>]

Good point. What is the license (and maturity) of Janino? AWProxy is also very new.

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
>>>>>>>>
>>>>>>>>
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

-- 

____________________________________________________
Rod Johnson
CEO, Interface21 - Spring Services from the Source
http://www.springframework.com

Founder, Spring Framework:
http://www.springframework.org

Author, "Expert One-on-One J2EE Development Without EJB"
(May 2004, with Juergen Hoeller).
http://www.amazon.com/exec/obidos/ASIN/0764558315/

Author, "Expert One-on-One J2EE Design and Development"
(October 2002).
http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/


____________________________________________________
Interface21 Limited
Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY
Registered in England and Wales No. 5187766
____________________________________________________