Re: [Springframework-developer] Extending Spring AOP

[Bob L. <cra...@cr...>]

OK. I'm not sure if this helps, but I submitted one patch the makes  
Enhancer.getMethods(...) public. This gives you the list of methods  
that will be in a proxy.

I had problems with proxy creation as well (not sure if they're the  
same as yours). The solution is to hold on to the proxy class  
(Enhancer.createClass()) and to pass in the callbacks to instances  
using Enhancer.registerCallbacks(...). Kind of annoying, but easy  
enough to abstract away.

Bob

On Dec 19, 2004, at 3:11 AM, Rob Harrop wrote:

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