Re: [Springframework-developer] Extending Spring AOP

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

Bob,

The biggest gripe with CGLIB support at the moment is that the 
ProxyCallbackFilter holds onto a lot of state which we don't want it to. 
However, we should be able to clear this out with some clever trickery - 
something I have planned for 1.1.4. The second major gripe is that 
methods called by the constructor are called during proxy construction 
and may reset bean state after the DI process occurs. I guess this is 
not a porblem you'll see with Dynaop but it is very annoying. Hopefully 
the CGLIB guys are going patch CGLIB to allow us to avoid this.

Rob

Bob Lee wrote:

> On Dec 19, 2004, at 2:58 AM, Rod Johnson wrote:
>
>> Bob
>>
>> "Gutting our implementation" isn't quite accurate: proxy creation is  
>> behind an implementation, so it has purely localized effect.
>
>
> Didn't mean to sound inflammatory. Simply meant "replacing the insides."
>
>> Our experience has been that CGLIB is getting harder and harder to  
>> maintain, for some of what we need to do with it.
>
>
> Am I going to fall in the same trap?
>
>> Have to agree with RJ's point re dynamic proxies being preferable 
>> for  various reasons, anyway.
>
>
> The only reason I would prefer DPs is serialization. There are still  
> some problems with serializing circular class proxy references  
> transparently, though most people don't serialize proxies directly  
> anyway, and there is a workaround.
>
> Class proxies are better performance wise. For methods with no  
> interceptors, you can delegate directly to the target object or mixin  
> without creating an object array, boxing arguments, etc.
>
> I do wish cglib created it's own classloader rather than injecting  
> classes directly into the current one. AFAIK, they do this so proxies  
> can call package-private methods. I'd prefer they just created a new  
> class loader. This would alleviate any security concerns.
>
> Bob
>
>> Rgds
>> Rod
>>
>> Bob Lee wrote:
>>
>>> Out of curiosity, what problems are you having with cglib that 
>>> could  justify completely gutting your implementation?
>>> You really can't optimize any more than cglib. The only reason  
>>> AspectWerkz is faster in those micro benchmarks literally amounts 
>>> to  one object array creation. If it's that big of a deal, 
>>> statically  analyze the bytecode of your interceptor class. If it 
>>> never uses the  argument array, use a callback type that doesn't 
>>> create it. This  would be insane, but it doesn't force the 
>>> performance optimization on  the user.
>>> Also, notice that all of the methods in the AWBench that take  
>>> arguments, take a single int, which requires boxing. Not something  
>>> that we should worry about.
>>> In reality, real world stuff like invoking a mixin in Dynaop is as  
>>> fast as AW.
>>> I'm just wondering because I'm personally liking cglib more and 
>>> more.  I just submitted a couple patches to support Dynaop and found 
>>> their  code pretty easy to maintain. Also, I've completely dumped 
>>> dynamic  proxies in favor of cglib proxies.
>>> Bob
>>> On Dec 17, 2004, at 8:50 AM, Eugene Kuleshov wrote:
>>>
>>>> Folks,
>>>>
>>>>   That is an interesting discussion...
>>>>
>>>>   I've been looking to Janino for quite some time (actually it is  
>>>> used for some of the ASM's tests, especially to test for ASMifier  
>>>> tool).
>>>>
>>>>   I can say that maintainer is quite busy and there still some 
>>>> bugs  (at least one we hit from ASM test cases).
>>>>
>>>>   However there is some activity going on about moving Janino to  
>>>> Codehaus and also it has been suggested to port Janino to use ASM 
>>>> as  an internal bytecode toolkit underneath (right now it has its 
>>>> own  proprietory bytecode manipulation framework). Also I know 
>>>> that  Groovy and AW teams has been looking at Janino in order to 
>>>> use it  for bytecode generation. The main reason is that Janino has 
>>>> extremly  simplistic AST model, that allows to generate high level 
>>>> language  constructs in memory without parsing strings (so, you can 
>>>> skip  Velocity all together, which would be an important part in 
>>>> order to  reduce dependencies for core AOP framework).
>>>>
>>>>   regards,
>>>>   Eugene
>>>>
>>>>
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> 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
>>
>>
>> -- 
>>
>> ____________________________________________________
>> 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
>> ____________________________________________________
>>
>>
>>
>> -------------------------------------------------------
>> 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
>
>