Menu
▾
▴
springframework-developer
|
From: Rob H. <ro...@ca...> - 2004-12-17 12:42:53
|
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 |
|
From: Rod J. <ro...@in...> - 2004-12-17 12:53:43
|
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 ____________________________________________________ |
|
From: Rob H. <ro...@ca...> - 2004-12-17 12:59:11
|
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 >> > |
|
From: Dmitriy K. <dko...@ru...> - 2004-12-17 13:47:40
|
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 |
|
From: Rod J. <ro...@in...> - 2004-12-17 14:39:11
|
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 > -- ____________________________________________________ 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 ____________________________________________________ |
|
From: Colin S. <col...@ex...> - 2004-12-17 14:46:26
|
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 >> > |
|
From: Dmitriy K. <dko...@ru...> - 2004-12-17 14:56:22
|
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 |
|
From: Rob H. <ro...@ca...> - 2004-12-17 15:41:10
|
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 > > |
|
From: Rod J. <ro...@in...> - 2004-12-17 15:50:27
|
+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. |
|
From: Colin S. <col...@ex...> - 2004-12-17 15:51:17
|
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 >>>>>>> |
|
From: Rod J. <ro...@in...> - 2004-12-17 15:57:32
|
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 ____________________________________________________ |
|
From: Rob H. <ro...@ca...> - 2004-12-17 16:01:43
|
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 >> > |
|
From: Eugene K. <eu...@md...> - 2004-12-17 16:50:57
|
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 |
|
From: Bob L. <cra...@cr...> - 2004-12-19 01:16:06
|
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 |
|
From: Rod J. <ro...@in...> - 2004-12-19 10:59:15
|
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 ____________________________________________________ |
|
From: Rob H. <ro...@ca...> - 2004-12-19 11:09:12
|
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 >> > |
|
From: Bob L. <cra...@cr...> - 2004-12-19 17:43:45
|
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 |
|
From: Bob L. <cra...@cr...> - 2004-12-19 17:43:46
|
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 |
|
From: Rob H. <ro...@ca...> - 2004-12-20 09:03:16
|
Bob, The biggest gripe with CGLIB support at the moment is that the ProxyCallbackFilter holds onto a lot of state which we don't want it to. However, we should be able to clear this out with some clever trickery - something I have planned for 1.1.4. The second major gripe is that methods called by the constructor are called during proxy construction and may reset bean state after the DI process occurs. I guess this is not a porblem you'll see with Dynaop but it is very annoying. Hopefully the CGLIB guys are going patch CGLIB to allow us to avoid this. Rob Bob Lee wrote: > On Dec 19, 2004, at 2:58 AM, Rod Johnson wrote: > >> Bob >> >> "Gutting our implementation" isn't quite accurate: proxy creation is >> behind an implementation, so it has purely localized effect. > > > Didn't mean to sound inflammatory. Simply meant "replacing the insides." > >> Our experience has been that CGLIB is getting harder and harder to >> maintain, for some of what we need to do with it. > > > Am I going to fall in the same trap? > >> Have to agree with RJ's point re dynamic proxies being preferable >> for various reasons, anyway. > > > The only reason I would prefer DPs is serialization. There are still > some problems with serializing circular class proxy references > transparently, though most people don't serialize proxies directly > anyway, and there is a workaround. > > Class proxies are better performance wise. For methods with no > interceptors, you can delegate directly to the target object or mixin > without creating an object array, boxing arguments, etc. > > I do wish cglib created it's own classloader rather than injecting > classes directly into the current one. AFAIK, they do this so proxies > can call package-private methods. I'd prefer they just created a new > class loader. This would alleviate any security concerns. > > Bob > >> Rgds >> Rod >> >> Bob Lee wrote: >> >>> Out of curiosity, what problems are you having with cglib that >>> could justify completely gutting your implementation? >>> You really can't optimize any more than cglib. The only reason >>> AspectWerkz is faster in those micro benchmarks literally amounts >>> to one object array creation. If it's that big of a deal, >>> statically analyze the bytecode of your interceptor class. If it >>> never uses the argument array, use a callback type that doesn't >>> create it. This would be insane, but it doesn't force the >>> performance optimization on the user. >>> Also, notice that all of the methods in the AWBench that take >>> arguments, take a single int, which requires boxing. Not something >>> that we should worry about. >>> In reality, real world stuff like invoking a mixin in Dynaop is as >>> fast as AW. >>> I'm just wondering because I'm personally liking cglib more and >>> more. I just submitted a couple patches to support Dynaop and found >>> their code pretty easy to maintain. Also, I've completely dumped >>> dynamic proxies in favor of cglib proxies. >>> Bob >>> On Dec 17, 2004, at 8:50 AM, Eugene Kuleshov wrote: >>> >>>> Folks, >>>> >>>> That is an interesting discussion... >>>> >>>> I've been looking to Janino for quite some time (actually it is >>>> used for some of the ASM's tests, especially to test for ASMifier >>>> tool). >>>> >>>> I can say that maintainer is quite busy and there still some >>>> bugs (at least one we hit from ASM test cases). >>>> >>>> However there is some activity going on about moving Janino to >>>> Codehaus and also it has been suggested to port Janino to use ASM >>>> as an internal bytecode toolkit underneath (right now it has its >>>> own proprietory bytecode manipulation framework). Also I know >>>> that Groovy and AW teams has been looking at Janino in order to >>>> use it for bytecode generation. The main reason is that Janino has >>>> extremly simplistic AST model, that allows to generate high level >>>> language constructs in memory without parsing strings (so, you can >>>> skip Velocity all together, which would be an important part in >>>> order to reduce dependencies for core AOP framework). >>>> >>>> regards, >>>> Eugene >>>> >>>> >>>>> Good point. What is the license (and maturity) of Janino? AWProxy >>>>> is also very new. >>>>> Colin Sampaleanu wrote: >>>>> >>>>>> One concern with AspectWerkz is the LGPL license. While >>>>>> Hibernate is also LGPL licensed, it is less a core part of >>>>>> Spring than the AOP stuff is. Now both Hibernate and AspectWerkz >>>>>> have a 'clarifying' statement about their interpretation of the >>>>>> LGPL: >>>>>> http://aspectwerkz.codehaus.org/license.html >>>>>> such that there is less ambiguity (in theory) about linkage to >>>>>> it, but I would be a bit reticent to have the main (non-proxy) >>>>>> AOP implementation in Spring be based on AspectWerkz because of >>>>>> concerns that Spring using organizations would have about LGPL. >>>>>> Whatever it's intentions, the LGPL is so badly worded that a >>>>>> number of companies will simply not use any libraries which are >>>>>> LGPL licensed... >>>>>> >>>>>> Colin >>>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> SF email is sponsored by - The IT Product Guide >>>> Read honest & candid reviews on hundreds of IT Products from real >>>> users. >>>> Discover which products truly live up to the hype. Start reading >>>> now. http://productguide.itmanagersjournal.com/ >>>> _______________________________________________ >>>> Springframework-developer mailing list >>>> Spr...@li... >>>> https://lists.sourceforge.net/lists/listinfo/springframework- >>>> developer >>> >>> ------------------------------------------------------- >>> SF email is sponsored by - The IT Product Guide >>> Read honest & candid reviews on hundreds of IT Products from real >>> users. >>> Discover which products truly live up to the hype. Start reading >>> now. http://productguide.itmanagersjournal.com/ >>> _______________________________________________ >>> Springframework-developer mailing list >>> Spr...@li... >>> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> >> -- >> >> ____________________________________________________ >> Rod Johnson >> CEO, Interface21 - Spring Services from the Source >> http://www.springframework.com >> >> Founder, Spring Framework: >> http://www.springframework.org >> >> Author, "Expert One-on-One J2EE Development Without EJB" >> (May 2004, with Juergen Hoeller). >> http://www.amazon.com/exec/obidos/ASIN/0764558315/ >> >> Author, "Expert One-on-One J2EE Design and Development" >> (October 2002). >> http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/ >> >> >> ____________________________________________________ >> Interface21 Limited >> Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent >> DA1 2JY >> Registered in England and Wales No. 5187766 >> ____________________________________________________ >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading >> now. http://productguide.itmanagersjournal.com/ >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Rob H. <ro...@ca...> - 2004-12-17 15:58:40
|
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 > > |
|
From: Rod J. <ro...@in...> - 2004-12-17 16:06:32
|
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 ____________________________________________________ |
|
From: R.J. L. <rjl...@co...> - 2004-12-19 04:19:41
|
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 |
|
From: Colin S. <col...@ex...> - 2004-12-17 16:27:46
|
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 >>>>>>>>> |
|
From: Dmitriy K. <dko...@ru...> - 2004-12-17 16:06:16
|
+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 |
