[aspectwerkz-dev] Re: [aspectwerkz-user] Re: setTarget and perInstance behaviour problems

Hey Charles.

redirecting to dev list

On Thu, 07 Oct 2004 11:34:27 +1000, Charles Blaxland
<charles.blaxland-FAZdQ5MDKtsgsgBzLPpwKhL4W9x8LtSr@public.gmane.org> wrote:
> Thanks Jonas,
> 
> I can probably wait for "real" perInstance support... I'm in no hurry
> for it right now.

Ok, great. You will have it in some months anyway.

> 
> setTarget is pretty much essential for what I'm trying to do, so any
> support you can add for it would be very much appreciated.  WRT
> setTarget under JIT mode... do you think it will *ever* be possible to
> have this work?  Is it just a matter of finding the time to implement
> it, or is it simply impossible?

It is a problem with reentrancy, making sure that each stack frame has
its own correct 'target'.
We solve this in non-jit code in 1.0. There are ways of doing it in
JIT compiled code as well. But we have not had the time (not highest
prio right now). We need to make sure that overall perf. is not
affected. But if it is something that is needed, then we will add it.

/Jonas

> 
> Cheers,
> Charles
> 
> Jonas Bonér wrote:
> 
> >HI Charles.
> 
> 
> >
> >Thanks for the description. Very interesting things you are working on.
> >
> >For the object identity problem for perinstance, I think that the best
> >way for you would be to write your own 'aspect container'. It is not
> >as hard as it sounds. You just have to subclass the
> >AbstractAspectContainer or implement the AspectContainer interface. If
> >you look into the sources of the AbstractAspectContainer you can see
> >that the perInstance target instances are now kept in a map, you need
> >to tweak this to suite your needs.
> >
> >For the setTarget, we can add it, but it will will only work for the
> >non-jit impl. This might be good enough for you (the only drawback is
> >that you will get a bit worse performance, but it is good enough for
> >most situations). For the JIT mode I can't do much write now. We will
> >however add support for "real" per instance aspects in upcoming
> >releases.
> >
> >You are right that we would benefit from having a proxy impl as well.
> >This is something we have been thinking about, but...to many things to
> >do.
> >
> >I hope it works out for you.
> >
> >/Jonas
> >
> >
> >
> >On Tue, 05 Oct 2004 11:09:25 +1000, Charles Blaxland
> ><charles.blaxland-FAZdQ5MDKtsgsgBzLPpwKhL4W9x8LtSr@public.gmane.org> wrote:
> >
> >
> >>Hi Jonas,
> >>
> >>In answer to your questions about use cases, I'm currently writing a
> >>transparent persistence layer for POJOs.  Its based around object
> >>versioning - when persistent objects are modified, a new version (clone)
> >>is created.  Each thread maintains a current "perspective" - ie: the
> >>version of the persistent graph that it is currently looking at.
> >>
> >>I am using aspectwerkz to intercept method calls on persistent objects
> >>and transparently redirect them to the correct target instance (version)
> >>for the calling thread's perspective.  So the instance that the caller
> >>invokes the method on originally may not be the instance the method
> >>actually runs on.  This is why I need a "setTarget" method.
> >>
> >>I can see setTarget being useful in other situations though.  One that
> >>springs to mind is dynamic proxying - the ability to proxy a particular
> >>object so you can plug in different implementations at runtime (or a
> >>remote impl, or a mock...).  Had a quick skip over to JBoss AOP and it
> >>looks like their API supports it.
> >>
> >>As for perInstance, I am introducing a mixin into every persistent
> >>object instance to hold onto (among other things) a UUID and a list of
> >>available object versions.  To guarantee correct behaviour I need this
> >>to really be per instance (ie: "==").  Otherwise I'd end up with two
> >>different persistent object instances with the same persistent identity
> >>(UUID).
> >>
> >>Anyway, hope this clarifies what I'm trying to do and why I need this
> >>functionality.
> >>
> >>Cheers,
> >>Charles
> >>
> >>
> >>
> >>Jonas Bonér wrote:
> >>
> >>
> >>
> >>>Hi Charles.
> >>>
> >>>The current perInstance impl, is not really sole per instance only,
> >>>but is more a matter of scope.  The instance are simply put in a Map.
> >>>In which does not equals() work, we could rely on hashCode, but since
> >>>this methods should always be "paired", is it really a point? What
> >>>usecase do you have? We will impl "real" per instance deployment in a
> >>>near future.
> >>>
> >>>The setTargetInstance method was removed since it is error-prone and I
> >>>did not really see a use case for it. If you f.e. use JIT (or the
> >>>upcoming 2.0) then changing the target instance will not affect the
> >>>actual invocation of the target method, since this is statically
> >>>compiled at runtime. E.g you will have the "wrong" target instance
> >>>returned from getTargetInstance. What is your usecase for such a
> >>>behavior? We could readd it , but then I need to be convinced that it
> >>>_reallly_ makes sense.
> >>>
> >>>/Jonas
> >>>
> >>>
> >>>On Mon, 4 Oct 2004 14:21:28 +1000 (EST), Charles Blaxland
> >>><charles_blaxland-/[email protected]> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Hi all,
> >>>>
> >>>>I've just upgraded to AW 1.0RC3 from beta1 (I'm a bit
> >>>>behind the times), and I can no longer find any way to
> >>>>change the target instance (eg: for a method call
> >>>>joinpoint) within my advice.  I used to do this with
> >>>>JoinPoint.setTargetInstance.  Is there an equivalent
> >>>>method in RC3?  Looking through the code I see a
> >>>>method "setTarget" in JoinPointBase which is commented
> >>>>out?
> >>>>
> >>>>Also, I've noticed that when you deploy an aspect with
> >>>>the perInstance model, if two *different* advised
> >>>>instances are equal according to their "equals"
> >>>>methods then they use the *same* aspect instance.  I
> >>>>would have expected that they would use different
> >>>>aspect instances, as "perInstance" to me implies an
> >>>>object identity comparison, not an "equals"
> >>>>comparison.  Is this behaviour intentional?
> >>>>
> >>>>Thanks,
> >>>>Charles
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> 
>