springframework-developer — Spring Framework developers list

[Springframework-developer] JDBC query convenience methods with arg types

[<jue...@we...>]

Thomas,
=20
I've just added overloaded =
"queryForList"/"queryForObject"/"queryForLong"/"queryForInt" methods =
with arg types to JdbcOperations and JdbcTemplate, to address the =
following issue:
=20
http://opensource.atlassian.com/projects/spring/browse/SPR-561
=20
It would be great if you could give this a try against Oracle. I suppose =
that it should work nicely with a properly specified SQL type for the =
NULL value.
=20
Juergen

Re: [Springframework-developer] Extending Spring AOP

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

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

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

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

Re: [Springframework-developer] Extending Spring AOP

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

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
> 

-- 

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

RE: [Springframework-developer] Extending Spring AOP

[R.J. L. <rjl...@co...>]

Hey guys,

Just wanted to add my two cents - didn't see the security manager problems
mentioned anywhere -

CgLib causes a whole host of security policy problems when dealing with some
shared JVM environments - which all too often exist in lower-class hosting
situations. As such, moving to a byte-code engineering approach as default
will break some users of hosting at companies like AOIndustries.com  - JDK
DPs don't have this same side effect. This has been a problem when using
Hibernate, as there have been times where CgLib has been tightly integrated
in that framework as well. Doesn't affect me anymore, but I feel their pain.

Anyway, just some food for thought - Cheers,
R.J.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Rod Johnson
Sent: Friday, December 17, 2004 10:06 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Extending Spring AOP

I agree. JDK DPs should be the default (and preferred) solution. They are
simple and add no binary dependencies. They are also very quick to create.

The one thing that DPs can't do--proxy classes, rather than interfaces--is
not a recommended option in general.

Rob Harrop wrote:
> I wasn't planning on having the AspectWerks proxy being the main 
> implementation. My plan was to keep the JDK proxy as the main 
> implementation because of its simplicity, replace the CGLIB proxy with 
> Janino as the second proxy of choice and then provide AspectWerkz as a 
> low maintenance, high performance choice for the core advice types 
> that we have now. I think that your concerns about LGPL fit with this 
> vision as well.
> 
> Rob
> 
> 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_prox
>>> y_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-develope
>> r
>>
>>
> 
> 
> -------------------------------------------------------
> 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

Re: [Springframework-developer] Extending Spring AOP

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

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

[Springframework-developer] spring build.173 Build Successful

[<al...@jt...>]

<html><head>
<style>
.white { color:#FFFFFF }.index { background-color:#FFFFFF }.index-passed { =
color:#004400 }.index-failed { color:#FF0000; font-weight:bold }.index-head=
er { font-weight:bold }.link { font-family:arial,helvetica,sans-serif; font=
-size:10pt; color:#FFFFFF; text-decoration:none; }.tab-table { margin: 0em =
0em 0.5em 0em; }.tabs { font-family:arial,helvetica,sans-serif; font-size:8=
pt; color:#000000; font-weight:bold; padding: 0em 2em; background-color:#EE=
EEEE; }.tabs-link { color:#000000; text-decoration:none; }.tabs-link:visite=
d { color:#000000; text-decoration:none; }.tabs-selected { font-family:aria=
l,helvetica,sans-serif; font-size:8pt; color:#000000; font-weight:bold; pad=
ding: 0em 2em; }.tabs-selected { border: inset; }.header-title { font-famil=
y:arial,helvetica,sans-serif; font-size:12pt; color:#000000; font-weight:bo=
ld; }.header-label { font-weight:bold; }.header-data { font-family:arial,he=
lvetica,sans-serif; font-size:10pt; color:#000000; }.modifications-data { f=
ont-family:arial,helvetica,sans-serif; font-size:8pt; color:#000000; }.modi=
fications-sectionheader { background-color:#000066; font-family:arial,helve=
tica,sans-serif; font-size:10pt; color:#FFFFFF; }.modifications-oddrow { ba=
ckground-color:#CCCCCC }.modifications-evenrow { background-color:#FFFFCC }=
.changelists-oddrow { background-color:#CCCCCC }.changelists-evenrow { back=
ground-color:#FFFFCC }.changelists-file-spacer { background-color:#FFFFFF }=
.changelists-file-evenrow { background-color:#EEEEEE }.changelists-file-odd=
row { background-color:#FFFFEE }.changelists-file-header { background-color=
:#666666; font-family:arial,helvetica,sans-serif; font-size:8pt; color:#FFF=
FFF; }.compile-data { font-family:arial,helvetica,sans-serif; font-size:8pt=
; color:#000000; }.compile-error-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#FF0000; }.compile-warn-data { font-family:arial,=
helvetica,sans-serif; font-size:8pt; color:#CC9900; }.compile-sectionheader=
 { background-color:#000066; font-family:arial,helvetica,sans-serif; font-s=
ize:10pt; color:#FFFFFF; }.distributables-data { font-family:arial,helvetic=
a,sans-serif; font-size:8pt; color:#000000; }.distributables-sectionheader =
{ background-color:#000066; font-family:arial,helvetica,sans-serif; font-si=
ze:10pt; color:#FFFFFF; }.distributables-oddrow { background-color:#CCCCCC =
}.unittests-sectionheader { background-color:#000066; font-family:arial,hel=
vetica,sans-serif; font-size:10pt; color:#FFFFFF; }.unittests-oddrow { back=
ground-color:#CCCCCC }.unittests-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#000000; }.unittests-error { font-family:arial,he=
lvetica,sans-serif; font-size:8pt; color:#901090; }.unittests-failure { fon=
t-family:arial,helvetica,sans-serif; font-size:8pt; color:#FF0000; }.checks=
tyle-oddrow { background-color:#CCCCCC }.checkstyle-data { font-family:aria=
l,helvetica,sans-serif; font-size:8pt; color:#000000; }.checkstyle-sectionh=
eader { background-color:#000066; font-family:arial,helvetica,sans-serif; f=
ont-size:10pt; color:#FFFFFF; }
</style>
</head><body>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"header-title">BUILD COMPLETE&nbsp;-&nbsp;     =
               build.173</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build:&nbsp;</span>12/19/2004 00:16:36</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>21 minutes 36 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed:&nbsp;</span>12/18/2004 13:00:23</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try:&nbsp;</span>Made protected instance variables accessible before trying=
 to set them.Improved Javadoc.</td></tr></table><p>
<p>
<p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"><tr><td class=
=3D"compile-sectionheader">                        &nbsp;Errors/Warnings: (=
6)                    </td></tr><tr><td><pre class=3D"compile-data">Note: S=
ome input files use or override a deprecated API.<br class=3D"none"/>Note: =
Recompile with -deprecation for details.<br class=3D"none"/>Note: /jteam/bu=
ild2/checkout/spring/spring/mock/org/springframework/mock/web/MockHttpSessi=
on.java uses or overrides a deprecated API.<br class=3D"none"/>Note: Recomp=
ile with -deprecation for details.<br class=3D"none"/>Note: Some input file=
s use or override a deprecated API.<br class=3D"none"/>Note: Recompile with=
 -deprecation for details.<br class=3D"none"/></pre></td></tr></table><p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"><tr><td class=
=3D"compile-sectionheader">                        &nbsp;Javadoc Errors/War=
nings: (26)                    </td></tr><tr><td><pre class=3D"compile-data=
">/jteam/build2/checkout/spring/spring/src/org/springframework/jdbc/support=
/lob/OracleLobHandler.java:76: warning - Tag @see: reference not found: ora=
cle.sql.BLOB<br/>/jteam/build2/checkout/spring/spring/src/org/springframewo=
rk/jdbc/support/lob/OracleLobHandler.java:76: warning - Tag @see: reference=
 not found: oracle.sql.CLOB<br/>/jteam/build2/checkout/spring/spring/src/or=
g/springframework/jdbc/support/lob/OracleLobHandler.java:115: warning - Tag=
 @see: reference not found: oracle.sql.BLOB#DURATION_SESSION<br/>/jteam/bui=
ld2/checkout/spring/spring/src/org/springframework/jdbc/support/lob/OracleL=
obHandler.java:115: warning - Tag @see: reference not found: oracle.sql.BLO=
B#MODE_READWRITE<br/>/jteam/build2/checkout/spring/spring/src/org/springfra=
mework/jdbc/support/lob/OracleLobHandler.java:115: warning - Tag @see: refe=
rence not found: oracle.sql.CLOB#DURATION_SESSION<br/>/jteam/build2/checkou=
t/spring/spring/src/org/springframework/jdbc/support/lob/OracleLobHandler.j=
ava:115: warning - Tag @see: reference not found: oracle.sql.CLOB#MODE_READ=
WRITE<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/jdbc=
/support/lob/OracleLobHandler.java:154: warning - Tag @see: reference not f=
ound: oracle.jdbc.OracleConnection<br/>/jteam/build2/checkout/spring/spring=
/src/org/springframework/jdbc/support/lob/OracleLobHandler.java:164: warnin=
g - Tag @see: reference not found: oracle.sql.BLOB#createTemporary<br/>/jte=
am/build2/checkout/spring/spring/src/org/springframework/jdbc/support/lob/O=
racleLobHandler.java:164: warning - Tag @see: reference not found: oracle.s=
ql.CLOB#createTemporary<br/>/jteam/build2/checkout/spring/spring/src/org/sp=
ringframework/jdbc/support/nativejdbc/JBossNativeJdbcExtractor.java:49: war=
ning - Tag @see: reference not found: org.jboss.resource.adapter.jdbc.Wrapp=
edConnection#getUnderlyingConnection<br/>/jteam/build2/checkout/spring/spri=
ng/src/org/springframework/jdbc/support/nativejdbc/JBossNativeJdbcExtractor=
.java:49: warning - Tag @see: reference not found: org.jboss.resource.adapt=
er.jdbc.WrappedStatement#getUnderlyingStatement<br/>/jteam/build2/checkout/=
spring/spring/src/org/springframework/jdbc/support/nativejdbc/JBossNativeJd=
bcExtractor.java:49: warning - Tag @see: reference not found: org.jboss.res=
ource.adapter.jdbc.WrappedResultSet#getUnderlyingResultSet<br/>/jteam/build=
2/checkout/spring/spring/src/org/springframework/jdbc/support/nativejdbc/We=
bLogicNativeJdbcExtractor.java:45: warning - Tag @see: reference not found:=
 weblogic.jdbc.extensions.WLConnection#getVendorConnection<br/>/jteam/build=
2/checkout/spring/spring/src/org/springframework/jdbc/support/nativejdbc/We=
bSphereNativeJdbcExtractor.java:34: warning - Tag @see: reference not found=
: com.ibm.ws.rsadapter.jdbc.WSJdbcConnection<br/>/jteam/build2/checkout/spr=
ing/spring/src/org/springframework/jdbc/support/nativejdbc/WebSphereNativeJ=
dbcExtractor.java:34: warning - Tag @see: reference not found: com.ibm.ws.r=
sadapter.jdbc.WSJdbcUtil#getNativeConnection<br/>/jteam/build2/checkout/spr=
ing/spring/src/org/springframework/jdbc/support/nativejdbc/WebSphereNativeJ=
dbcExtractor.java:34: warning - Tag @see: reference not found: com.ibm.ejs.=
cm.proxy.ConnectionProxy#getPhysicalConnection<br/>/jteam/build2/checkout/s=
pring/spring/src/org/springframework/orm/ibatis/SqlMapClientFactoryBean.jav=
a:170: warning - Tag @see: reference not found: com.ibatis.sqlmap.engine.tr=
ansaction.jdbc.JdbcTransactionConfig<br/>/jteam/build2/checkout/spring/spri=
ng/src/org/springframework/orm/ibatis/SqlMapClientFactoryBean.java:170: war=
ning - Tag @see: reference not found: com.ibatis.sqlmap.engine.transaction.=
jta.JtaTransactionConfig<br/>/jteam/build2/checkout/spring/spring/src/org/s=
pringframework/orm/ibatis/SqlMapClientFactoryBean.java:198: warning - Tag @=
see: reference not found: com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTra=
nsactionConfig<br/>/jteam/build2/checkout/spring/spring/src/org/springframe=
work/orm/ibatis/SqlMapClientFactoryBean.java:198: warning - Tag @see: refer=
ence not found: com.ibatis.sqlmap.engine.transaction.jta.JtaTransactionConf=
ig<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/transac=
tion/jta/WebLogicJtaTransactionManager.java:67: warning - Tag @see: referen=
ce not found: weblogic.transaction.TransactionManager#forceResume<br/>/jtea=
m/build2/checkout/spring/spring/src/org/springframework/transaction/jta/Web=
LogicServerTransactionManagerFactoryBean.java:45: warning - Tag @see: refer=
ence not found: weblogic.transaction.TxHelper#getTransactionManager<br/>/jt=
eam/build2/checkout/spring/spring/src/org/springframework/transaction/jta/W=
ebSphereTransactionManagerFactoryBean.java:47: warning - Tag @see: referenc=
e not found: com.ibm.ws.Transaction.TransactionManagerFactory#getTransactio=
nManager<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/t=
ransaction/jta/WebSphereTransactionManagerFactoryBean.java:47: warning - Ta=
g @see: reference not found: com.ibm.ejs.jts.jta.JTSXA#getTransactionManage=
r<br/>/jteam/build2/checkout/spring/spring/src/org/springframework/transact=
ion/jta/WebSphereTransactionManagerFactoryBean.java:47: warning - Tag @see:=
 reference not found: com.ibm.ejs.jts.jta.TransactionManagerFactory#getTran=
sactionManager<br/>/jteam/build2/checkout/spring/spring/src/org/springframe=
work/web/servlet/handler/metadata/PathMap.java:31: warning - @@org.apache.c=
ommons.attributes.Indexed() is an unknown tag.<br/></pre></td></tr></table>=
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"unittests-sectionheader">       =
            &nbsp;Unit Tests: (2085)                </td></tr><tr><td class=
=3D"unittests-data" colspan=3D"2">                            All Tests Pas=
sed                        </td></tr><tr><td><table width=3D"98%" border=3D=
"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"></table></td></tr>=
<tr></tr><tr><td colspan=3D"2">&nbsp;</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"1" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"6" class=3D"modifications-sectionheader">   =
                 &nbsp;Modifications since last build:&nbsp;               =
     (6)                </td></tr><tr class=3D"modifications-evenrow"><td c=
lass=3D"modifications-data">modified</td><td class=3D"modifications-data">j=
ohnsonr</td><td class=3D"modifications-data">mock/org/springframework/test/=
AbstractDependencyInjectionSpringContextTests.java</td><td class=3D"modific=
ations-data">Made protected instance variables accessible before trying to =
set them.Improved Javadoc.</td></tr><tr class=3D"modifications-oddrow"><td =
class=3D"modifications-data">modified</td><td class=3D"modifications-data">=
johnsonr</td><td class=3D"modifications-data">mock/org/springframework/test=
/AbstractSpringContextTests.java</td><td class=3D"modifications-data">Made =
protected instance variables accessible before trying to set them.Improved =
Javadoc.</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifica=
tions-data">modified</td><td class=3D"modifications-data">johnsonr</td><td =
class=3D"modifications-data">mock/org/springframework/test/AbstractTransact=
ionalDataSourceSpringContextTests.java</td><td class=3D"modifications-data"=
>Made protected instance variables accessible before trying to set them.Imp=
roved Javadoc.</td></tr><tr class=3D"modifications-oddrow"><td class=3D"mod=
ifications-data">modified</td><td class=3D"modifications-data">johnsonr</td=
><td class=3D"modifications-data">mock/org/springframework/test/AbstractTra=
nsactionalSpringContextTests.java</td><td class=3D"modifications-data">Made=
 protected instance variables accessible before trying to set them.Improved=
 Javadoc.</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modific=
ations-data">modified</td><td class=3D"modifications-data">johnsonr</td><td=
 class=3D"modifications-data">mock/org/springframework/test/package.html</t=
d><td class=3D"modifications-data">Made protected instance variables access=
ible before trying to set them.Improved Javadoc.</td></tr><tr class=3D"modi=
fications-oddrow"><td class=3D"modifications-data">modified</td><td class=
=3D"modifications-data">dkopylenko</td><td class=3D"modifications-data">src=
/org/springframework/aop/framework/Cglib2AopProxy.java</td><td class=3D"mod=
ifications-data">Added inline comment</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"distributables-sectionheader">                =
        &nbsp;Deployments by this build:&nbsp;(16)                    </td>=
</tr><tr><td class=3D"distributables-data">Building jar: /jteam/build2/chec=
kout/spring/spring/dist/spring-core.jar</td></tr><tr class=3D"distributable=
s-oddrow"><td class=3D"distributables-data">Building jar: /jteam/build2/che=
ckout/spring/spring/dist/spring-aop.jar</td></tr><tr><td class=3D"distribut=
ables-data">Building jar: /jteam/build2/checkout/spring/spring/dist/spring-=
context.jar</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distr=
ibutables-data">Building jar: /jteam/build2/checkout/spring/spring/dist/spr=
ing-dao.jar</td></tr><tr><td class=3D"distributables-data">Building jar: /j=
team/build2/checkout/spring/spring/dist/spring-orm.jar</td></tr><tr class=
=3D"distributables-oddrow"><td class=3D"distributables-data">Building jar: =
/jteam/build2/checkout/spring/spring/dist/spring-web.jar</td></tr><tr><td c=
lass=3D"distributables-data">Building jar: /jteam/build2/checkout/spring/sp=
ring/dist/spring-webmvc.jar</td></tr><tr class=3D"distributables-oddrow"><t=
d class=3D"distributables-data">Building jar: /jteam/build2/checkout/spring=
/spring/dist/spring.jar</td></tr><tr><td class=3D"distributables-data">Buil=
ding jar: /jteam/build2/checkout/spring/spring/dist/spring-mock.jar</td></t=
r><tr class=3D"distributables-oddrow"><td class=3D"distributables-data">Bui=
lding war: /jteam/build2/checkout/spring/spring/autobuilds/apps/buildtest/d=
ist/buildtest.war</td></tr><tr><td class=3D"distributables-data">Building w=
ar: /jteam/build2/checkout/spring/spring/autobuilds/apps/buildtest/dist/bui=
ldtest.war</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distri=
butables-data">Building war: /jteam/build2/checkout/spring/spring/autobuild=
s/apps/buildtest/dist/buildtest.war</td></tr><tr><td class=3D"distributable=
s-data">Building jar: /jteam/build2/checkout/spring/spring/autobuilds/apps/=
jpetstore/war/WEB-INF/lib/jpetstore.jar</td></tr><tr class=3D"distributable=
s-oddrow"><td class=3D"distributables-data">Building war: /jteam/build2/che=
ckout/spring/spring/autobuilds/apps/jpetstore/dist/jpetstore.war</td></tr><=
tr><td class=3D"distributables-data">Building jar: /jteam/build2/checkout/s=
pring/spring/autobuilds/apps/jpetstore/war/WEB-INF/lib/jpetstore.jar</td></=
tr><tr class=3D"distributables-oddrow"><td class=3D"distributables-data">Bu=
ilding war: /jteam/build2/checkout/spring/spring/autobuilds/apps/jpetstore/=
dist/jpetstore.war</td></tr></table>
</body></html>

[Springframework-developer] Allow ApplicationContext to display more than 1 error on startup?

[Matt S. <sga...@us...>]

Hi Spring developers,

For an application I am working on, it would be nice to make the 
exception handling behavior of the ApplicationContext more similar to 
the DataBinder.  That is, when the application context is starting up, 
it would be nice to have a whole list of errors come up rather than only 
one error at a time.  So, assuming the XML file has a valid format, 
figure out *each* bean that is invalid and display *all* of those beans 
instead of doing it one-at-a-time.

How would you suggest I go about implementing such functionality, and 
would the Spring team be interested in including this functionality in 
the Spring core? I can certainly write it and implement it.

My use case is this:
- We allow users to define multiple databases, one of which is chosen 
when the user logs in (kind of like BugZilla or Rational's ClearQuest). 
We are building a GUI that allows users to graphically add databases 
which our app internally stores in a Spring application context. We 
would like to aggregate all the problems with the databases in the 
application context at once. This would be useful to detect, for 
example, if the network was down vs. just a single database is down.

I was thinking perhaps a new interface would be beneficial. Maybe

DebuggableApplicationContext extends ConfigurableApplicationContext {
/** Returns a Map of bean names to exceptions that lists the problems 
that would be encountered if the application context were to have its 
refresh() method called */
Map testBeanDefinitions();
}

What ideas do you guys have?  Below is Rod Johnson's initial response 
from the user forums.  Thanks!  - Matt

Interesting idea. Probably best to discuss on the Spring Developer 
mailing list.

There are certainly some technical challenges here, as one failure may 
make it impossible to even attempt to initialize other beans. But it may 
be possible to continue in some circumstances.

Rgds
Rod

Re: [Springframework-developer] HiveMind Support

[<jas...@ma...>]

On 17 Dec 2004, at 17:19, Rod Johnson wrote:
>> Thats great to know! I've been using lots of Tapestry + Spring + 
>> Hibernate lately and was a little worried that Tapestry 3.1 with all 
>> the HiveMind stuff might be painful to use what with all the HIveMind 
>> stuff everywhere - but this is great news!
> Must say that I'm still not entirely comfortable with this direction 
> of Tapestry. It smacks of a certain software company's policy of 
> bundling things :-)

:)

Agreed - I'd have much rather Tapestry be built on pure dependency 
injection and leave the container up to the developer to choose... I'm 
still not sure why we need HiveMind when we have Spring :)

James
-------
http://radio.weblogs.com/0112098/

Re: [Springframework-developer] HiveMind Support

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

> Thats great to know! I've been using lots of Tapestry + Spring + 
> Hibernate lately and was a little worried that Tapestry 3.1 with all the 
> HiveMind stuff might be painful to use what with all the HIveMind stuff 
> everywhere - but this is great news!
Must say that I'm still not entirely comfortable with this direction of Tapestry. It smacks of a 
certain software company's policy of bundling things :-)

But, sure, the Spring philosophy is that we integrate with things, if it brings value to our users.

Re: [Springframework-developer] Extending Spring AOP

[Eugene K. <eu...@md...>]

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

Re: [Springframework-developer] HiveMind Support

[<jas...@ma...>]

On 17 Dec 2004, at 16:24, Rob Harrop wrote:
> All,
>
> I've been looking into HiveMind and it is interesting to see that they 
> have integration with Spring to allow for services to be obtained from 
> Spring.

Thats great to know! I've been using lots of Tapestry + Spring + 
Hibernate lately and was a little worried that Tapestry 3.1 with all 
the HiveMind stuff might be painful to use what with all the HIveMind 
stuff everywhere - but this is great news!


>  I think we should produce the inverse of this and allow for services 
> to obtained from HiveMind in a Spring configuration file. What are 
> your thoughts?

Good idea; initially I wasn't sure of the user case, I mean why not 
just use Spring :) But I suppose Spring may want to fetch services out 
of HiveMind too, to implement services inside Spring which are 
dependent on services created inside HiveMind

James
-------
http://radio.weblogs.com/0112098/

Re: [Springframework-developer] HiveMind Support

[Dmitriy K. <dko...@ru...>]

I would say if there is an obvious demand for such integration then 
let's go for it.

Dmitriy.


Rob Harrop wrote:

> All,
>
> I've been looking into HiveMind and it is interesting to see that they 
> have integration with Spring to allow for services to be obtained from 
> Spring. I think we should produce the inverse of this and allow for 
> services to obtained from HiveMind in a Spring configuration file. 
> What are 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

Re: [Springframework-developer] Extending Spring AOP

[Colin S. <col...@ex...>]

That makes sense...

Rob Harrop wrote:

> I wasn't planning on having the AspectWerks proxy being the main 
> implementation. My plan was to keep the JDK proxy as the main 
> implementation because of its simplicity, replace the CGLIB proxy with 
> Janino as the second proxy of choice and then provide AspectWerkz as a 
> low maintenance, high performance choice for the core advice types 
> that we have now. I think that your concerns about LGPL fit with this 
> vision as well.
>
> Rob
>
> 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
>>>>>>>>>

[Springframework-developer] HiveMind Support

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

All,

I've been looking into HiveMind and it is interesting to see that they 
have integration with Spring to allow for services to be obtained from 
Spring. I think we should produce the inverse of this and allow for 
services to obtained from HiveMind in a Spring configuration file. What 
are your thoughts?

Rob

Re: [Springframework-developer] Extending Spring AOP

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

I agree. JDK DPs should be the default (and preferred) solution. They are simple and add no binary 
dependencies. They are also very quick to create.

The one thing that DPs can't do--proxy classes, rather than interfaces--is not a recommended option 
in general.

Rob Harrop wrote:
> I wasn't planning on having the AspectWerks proxy being the main 
> implementation. My plan was to keep the JDK proxy as the main 
> implementation because of its simplicity, replace the CGLIB proxy with 
> Janino as the second proxy of choice and then provide AspectWerkz as a 
> low maintenance, high performance choice for the core advice types that 
> we have now. I think that your concerns about LGPL fit with this vision 
> as well.
> 
> Rob
> 
> 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
>>
>>
> 
> 
> -------------------------------------------------------
> 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
____________________________________________________

Re: [Springframework-developer] Extending Spring AOP

[Dmitriy K. <dko...@ru...>]

+1 for making AWProxy as an additional option

Rob Harrop wrote:

> I wasn't planning on having the AspectWerks proxy being the main 
> implementation. My plan was to keep the JDK proxy as the main 
> implementation because of its simplicity, replace the CGLIB proxy with 
> Janino as the second proxy of choice and then provide AspectWerkz as a 
> low maintenance, high performance choice for the core advice types 
> that we have now. I think that your concerns about LGPL fit with this 
> vision as well.
>
> Rob
>
> 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
>>
>>
>
>
> -------------------------------------------------------
> 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

Re: [Springframework-developer] Extending Spring AOP

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

Janino is Apache licensed.

Rob

Rod Johnson wrote:

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

[Springframework-developer] Includes and DispatcherServlet

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

There is an interesting problem on the mailing lists - has any seen this 
before, it seems like the guy is having problems coming from 1.1 to1.1.3.

http://forum.springframework.org/viewtopic.php?t=2565&highlight=

Rob

Re: [Springframework-developer] Extending Spring AOP

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

I wasn't planning on having the AspectWerks proxy being the main 
implementation. My plan was to keep the JDK proxy as the main 
implementation because of its simplicity, replace the CGLIB proxy with 
Janino as the second proxy of choice and then provide AspectWerkz as a 
low maintenance, high performance choice for the core advice types that 
we have now. I think that your concerns about LGPL fit with this vision 
as well.

Rob

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

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
____________________________________________________

Re: [Springframework-developer] Extending Spring AOP

[Colin S. <col...@ex...>]

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

Re: [Springframework-developer] Extending Spring AOP

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

+1

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 :(
Not me, anyway.

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