Menu
▾
▴
RE: [Springframework-developer] Extending Spring AOP
|
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 |
