[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] AspectJ and memory management
|
Hi,
Not sure if this will help but my article on lazy loading using AspectJ
might give you some ideas along these lines?
http://www.onjava.com/pub/a/onjava/2004/03/17/lazyAspects.html
Cheers,
Russ
On 8 Aug 2004, at 04:53, Wes Isberg wrote:
Hi -
Basically, if a class A has a stateful "perthis" introduction X, which
adds an implementation of the interface Y to A, then I want to control
how instances of X are managed.
Lazy construction?
i.e.,
In AspectJ, you can declare that a class implements an interface
and you can define method(s) on another type; as a result, an
aspect can define the implementation of an interface on a class:
interface I { void m(); }
class C {}
aspect ImplementingIOnC {
declare parents: C implements I;
public void I.m() { ... }
}
(Introduction (a term that is deprecated in favor of
"inter-type declaration") and perthis aspects are different beasts.
ITD's provide mixin functionality. perthis or pertarget aspects
provide associations, but no changes to the type or to
method signatures.)
So there is only one object when C is instantiated, and it includes
anything defined on it from any aspects.
If you want to code the implementation of I using techniques
to control initialization or persistence of any state, you're
free to do so:
aspect ImplementingIOnC {
declare parents: C implements I;
public void I.m() { getIDelegate().m(); }
IImpl I.delegate
synchronized I I.getIDelegate() {
if (null == delegate) {
IImpl created = IImplFactory.create();
...
delegate = created;
}
return delegate;
}
}
Sometimes it helps to tailor the lifecycle for a specific target:
/** used for all I implementations (knows-about I and IImpl only) */
aspect ImplementingI { ... } // see above, without declare-parents
/** tailor I to C (knows-about both ImplementingI and C) */
aspect ImplementingIOnC {
declare parents: C implements I;
/** save I after closing C */
after (I i) returning : target(i) &&
execution(void C.close()) {
IImpl iimpl = i.delegate;
if (null != iimpl) {
iimpl.save();
}
}
}
As for per{this|target|cflow} aspects, if you do end up
interested in controlling initialization, you'll find the
programmer can't control when they are instantiated, but
you can manage aspect state to be lazy in the same way.
Hope this helps -
Wes
------------Original Message------------
From: Rickard Öberg <rickard@xxxxxxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Date: Sat, Aug-7-2004 12:24 PM
Subject: [aspectj-users] AspectJ and memory management
Hi!
I am investigating how it would be possible to implement memory
management techniques for introductions in AspectJ.
Basically, if a class A has a stateful "perthis" introduction X, which
adds an implementation of the interface Y to A, then I want to control
how instances of X are managed. Specifically, an instantiation of A
should not cause an instantiation of X. An invocation of Y on A must
enable X to be instantiated and loaded with persistent state, and
after
the invocation it must be possible to GC X (compare this with, for
example, JDO and EJB EntityBeans). This allows for the construction of
a
scalable domain model using introductions.
I've looked around in the documentation but can't find much info on
how
introductions are managed, in this sense. Is what I'm after possible
to
do in AspectJ?
If yes, then how? If no, then why not?
Thanks,
Rickard
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
