Re: [Springframework-developer] Extending Spring AOP

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

Bob,

Some of the specific problems we are having are related to proxying 
classes with no arg constructors and with deferring base class 
constructor calls when creating a proxy across all Callback 
implementations. There are a few memory related problems which I think 
we can fix but they require some strange workarounds. All in all, for 
our requirements it would be a better long term idea to have more 
control over proxy creation.

Rob

Rod Johnson wrote:

> Bob
>
> "Gutting our implementation" isn't quite accurate: proxy creation is 
> behind an implementation, so it has purely localized effect.
>
> Our experience has been that CGLIB is getting harder and harder to 
> maintain, for some of what we need to do with it.
>
> Have to agree with RJ's point re dynamic proxies being preferable for 
> various reasons, anyway.
>
> 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
>>
>