I got the impression we were doing this modification at compile time,
and not runtime... if so, wouldn't BCEL be better? ASM gives up a lot
of clarity (in my opinion) for sheer runtime performance.
Cris
On 5/18/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
> Bill,
>
> I had an idea of how we can go about it, although I got a little
> backed up to try it now. Do you have time to play with it?
>
> IIRC ASM bytecode reader uses callback mechanism to notify the writer
> when a certain piece of code (such as method) is parsed. In a non-
> transforming case the writer simply outputs everything the reader
> gives it. So how about this - when a callback is invoked for a method
> that we want to intercept, our transformer writes it into a method
> with a different name, at the same time generating a method with the
> original name that invokes the interceptor code and the newly created
> method. This way we can treat the method body as a black box, and
> still wrap it with custom code:
>
> Original:
>
> public void setX(Object x) {
> ... some code ...
> }
>
>
> Transformer output:
>
> public void setX(Object x) {
> beforeSetX();
> ___setX(x);
> afterSetX();
> }
>
> private void ____setX(Object x) {
> ... some code ...
> }
>
>
> Andrus
>
>
> On May 17, 2006, at 10:43 AM, Andrus Adamchik wrote:
>
> > Hi Bill,
> >
> > I will be working on the B3 release today. Once this is done, I'll
> > take a look at how we can do it with ASM.
> >
> > Andrus
> >
> >
> > On May 16, 2006, at 11:40 PM, Bill Dudney wrote:
> >
> >> Hey Andrus,
> >>
> >> I spent the bulk of my time investigating ASM route and I don't
> >> see a straightforward way to do the injection. Creating new
> >> methods is straightforward but injecting method calls around the
> >> original method is not so straightforward.
> >>
> >> Any ideas how that might work?
> >>
> >> Thanks,
> >>
> >> -bd-
> >>
> >> On May 16, 2006, at 10:22 AM, Andrus Adamchik wrote:
> >>
> >>> Bill,
> >>>
> >>> This confirms my suspicion that CGlib was not designed for such
> >>> use. Probably we may need to try using ASM directly. But of
> >>> course if anyone can get in touch with CGlib folks, it would be
> >>> nice to doublecheck with them.
> >>>
> >>> Andrus
> >>>
> >>>
> >>> On May 16, 2006, at 1:50 AM, Bill Dudney wrote:
> >>>
> >>>> Hi Andrus,
> >>>>
> >>>> Sorry I'm still not done.
> >>>>
> >>>> I've been searching and hacking for way to long now to try to
> >>>> get this code in. The basic problem is that like you I could not
> >>>> find a way to wrap the original implementation of the method
> >>>> using the CGLib implementation path that exists in the rest of
> >>>> the code. It appears to be easy with the Enhancer API.
> >>>>
> >>>> I prefer your approach to the Enhancer but I'm at a loss as to
> >>>> how to make it work. I'll try to get some more time tomorrow to
> >>>> look at it but I'm going to be very busy doing J1 stuff.
> >>>>
> >>>> Does anyone know if the CGLib folks are on IRC anywhere?
> >>>>
> >>>> TTFN,
> >>>>
> >>>> -bd-
> >>>>
> >>>> On May 4, 2006, at 7:15 PM, Andrus Adamchik wrote:
> >>>>
> >>>>> I need some help with CGLib. It is great for proxies, but our
> >>>>> enhancer changes the actual class instead of making a proxied
> >>>>> subclass. Such scenario is a pain... Maybe Jeff or someone else
> >>>>> has an idea how to implement the enhancing code below?
> >>>>>
> >>>>> Basically I am trying to inject code calling a static delegate
> >>>>> method in three places:
> >>>>>
> >>>>> 1. Property getter start: DataObjectDelegate.beforeGetProperty
> >>>>> 2. Property setter start: DataObjectDelegate.beforeSetProperty
> >>>>> 3. Property setter end: DataObjectDelegate.afterSetProperty
> >>>>>
> >>>>> I was able to implement a simpler case of creating synthetic
> >>>>> properties with getters and setters (InterfaceMethodInjector),
> >>>>> but got stuck with this one (see TODO's on the
> >>>>> DataObjectAccessorInjector). I suspect we'll have to use ASM
> >>>>> for that, but if anyone can figure a CGlib solution, please let
> >>>>> me know.
> >>>>>
> >>>>> Andrus
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> >
>
>
This archive was generated by hypermail 2.0.0 : Thu May 18 2006 - 20:57:57 EDT