Re: [Springframework-developer] Extending Spring AOP

[Alexandre V. <ava...@gm...>]

Hi guys

AWProxy code is indeed nothing since the proxy we generate is only is
a subclass of the
target class that delegates all methods / constructors to its
super.xxx(..)  (hence regular proxy limitation as regards final method
etc).
AWProxy as is is useless (see ProxyCompiler source code f.e.)
The value comes from the fact that the proxy compiler then pass it on
to the weaver (under the hood, no special VM configuration), and the
weaver does inject the AOP bytecode.
We don't have yet interface based / implementation delegation proxy
but that should be pretty much as easy.

AWProxy is powerfull in the way that our AOP engine is blessing the
proxy and handles it as the target class when it does the matching. In
a regular AOP world (f.e AJ / JBoss), ones would have to adapt each
pointcut to match on the proxy name (wich is quite hard to guess) or
to match on "hierarchical pointcuts", or other way - ie to care about
the proxy based architecture, which is the opposite of what we wanted.

As regards reusable ASM stuff, we have a bunch of utility methods in a
class named AsmHelper, and some reusable visitor (cglib has some
others) to take care of tricky things (f.e. detect the instruction
that is for the actual this() or super() in a constructor body etc).

Alex


On Mon, 20 Dec 2004 10:37:38 -0500, Eugene Kuleshov <eu...@md...> wrote:
> Rob,
> 
>    There is no code for this proposed ASM subproject. The idea was to
> analyse existing projects and identify common patterns for bytecode
> transformations. I can say right away that one of the most commonly used
> patterns is class proxy. It seems that AWProxy came very close to be
> generic enough and it is already ASM-based and perhaps Alex will not
> mind to generalize it to have no AW specifics.
> 
>    We would appreciate any input in this area.
> 
>    regards,
>    Eugene
> 
> > We are fine with direct bytecode manipulation, we just want to avoid it
> > if we can. Spring AOP ism't meant to have absolute raw performance.
> > Instead it is meant to over competitive performance in any easy to use
> > and understand package. With CGLIB, the biggest problem is that we cant
> > create specific bytecode for each advice type using CGLIB as is. With
> > Janino we can build specific Java code for each each advice type in a
> > proxy and then compile this all to bytecode. The compilation will be a
> > one off cost for class/advice chain combinations.
> >
> > We should be providing AWProxy support as well since it covers most of
> > our needs, but Janino is a possibility for the proxy platform for the
> > future features to be added to Spring AOP.
> >
> > The ASM sub-library you are talking about sounds nice and I will
> > certainly consider using it - can you send more details?
> >
> > Rob
> >
> > Eugene Kuleshov wrote:
> >
> >> Rob,
> >>
> >>   I'm not sure where you actually expecting to gain performance by
> >> using Janino. i believe that manually crafted bytecode will provide
> >> much better control. However if you are not confortable with direct
> >> bytecode manipulation you can use one of the existing high-level class
> >> proxy generators:
> >>
> >>   -- CGLIB (with an appropriate fixes and extensions that CGLIB team
> >> should take care of),
> >>   -- JBoss's Javaassist (closest to Janino in terms of providing
> >> Java-like granularity)
> >>   -- AWProxy (it is directly using ASM and provide enough features for
> >> common AOP needs)
> >>   -- Eric Bruneton of ASM recently proposed a new ASM subproject for
> >> most commonly used bytecode transformation (so, perhaps it could
> >> generalize CGLIB and/or AWProxy code) This will be the most
> >> lightweight but also most low level option.
> >>
> >>   I believe that at least one of the above options should give enough
> >> comfort to Spring dev team, to it will not be necessary to invent a
> >> bycicle and introduce new runtime dependencies.
> >>
> >>   Also, just for the record, class proxy will always cause security
> >> issues because they can't be instantiated without nested classloading
> >> or tricks with injecting classes into current classloaders (like CGLIB
> >> is doing), so you have to deal with it using Java security policy.
> >>
> >>   regards,
> >>   Eugene
> >>
> >>
> >>> Oliver,
> >>>
> >>> I think you are right on this point - Janino should in theory be much
> >>> faster since we can produce specific code for each advice type as
> >>> required, and we can do so easily. Coupled with some clever caching
> >>> we can do a lot with the Janino approach, make it very performant,
> >>> and we have full control over it. I am hoping to add this support in
> >>> time for 1.2 but I will be fixing current bugs with the CGLIB
> >>> implementation provided I can get the appropriate patches added to
> >>> CGLIB as required.
> >>>
> >>> Rob
> >>>
> >>> Oliver Hutchison wrote:
> >>>
> >>>> Using Janino is a great idea.
> >>>>
> >>>> A few months back I was playing around with implementing "abstract
> >>>> schema" for the Spring AOP  subsystem and I did some simple
> >>>> benchmarking
> >>>> of Janino, CGLIB and JDK proxies and found that Janino was surprisingly
> >>>> efficient given the extra processing it needs to do.
> >>>>
> >>>> I generated the proxies using raw java code rather with than a template
> >>>> system as I didn't want to have any additional dependencies but what
> >>>> would be really nice is if you could generate the AST directly and I
> >>>> believe this may be on the way.
> >>>>
> >>>> Janino also includes line number (but not local variable) info in the
> >>>> generated classes. So if you save the code to disk you can step through
> >>>> the proxy implementation!
> >>>> Oliver
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: spr...@li...
> >>>>> [mailto:spr...@li...]
> >>>>> On Behalf Of Rob Harrop
> >>>>> Sent: Friday, 17 December 2004 11:43 PM
> >>>>> To: spr...@li...
> >>>>> Subject: [Springframework-developer] Extending Spring AOP
> >>>>>
> >>>>>
> >>>>> 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
> >>>>>
> >>>>>
> 
>