Re: [Springframework-developer] Extending Spring AOP

[Rob H. <ro...@ca...>]

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