AOP Alliance (Java/J2EE AOP standard)

Dear all,

I have been thinking a lot about our last discussions.
My feelings are that we are on the right track. However, there is a lack 
of specification of what we want to achieve here.
So, I have wrote a paper about it. See the links on the web site: 
http://aopalliance.sf.net .

Everything is debatable !

Best,
Renaud.

-- 
Renaud Pawlak - (+33) 660 926417
5, avenue Fremiet, 75016 Paris, France
renaud@...

FYI, we just released the first version of our AOP framework:

Download: =20
http://dev2dev.bea.com/resourcelibrary/utilitiestools/monitoring.jsp

Short announcement on my blog:  http://freeroller.net/page/cbeust/2003072=
2

TheServerSide thread: =20
http://www.theserverside.com/home/thread.jsp?thread_id=3D20514

--=20
C=E9dric
http://beust.com/weblog

I believe the following program has the behavior that you want, except
that you keep talking about an instance of Observable (i.e. Log) that
doesn't exist, so I'm not sure.  But lets focus on the following simple
code.

What this code shows is that the byte array will not be allocated when
instances of Customer are created. It will only be allocated when you
call getLog. It does this using the standard simple mechanism Java uses
for this, which is to omit the initializer in the field declaration.

In what way is this not what you want?

public class Main {
	public static void main(String[] args) {
		Customer c =3D new Customer();
		System.out.println(c.log);
		System.out.println(Log.getLog(c));
	}

}

class Customer { }

aspect Log {
	byte[] Customer.log;
=09
	static byte[] getLog(Customer c) {
		if(c.log =3D=3D null) {
			c.log =3D new byte[100];
			System.out.println("initialized log");
		}
		return c.log;
	}
}

> -----Original Message-----
> From: aopalliance-discuss-admin@...
> [mailto:aopalliance-discuss-admin@...] On=20
> Behalf Of Rickard =D6berg
> Sent: Thursday, July 03, 2003 7:57 AM
> To: aopalliance-discuss@...
> Subject: [aopalliance-discuss] Re: aspectj inlines=20
> introductions (was RE: [aopalliance-discuss] help me catch up)
>=20
>=20
> Gregor Kiczales wrote:
> > I'm still not getting it.
> >=20
> > Can we try to construct a concrete piece of code that shows=20
> the problem.
>=20
> Sounds like a good idea.
>=20
> > Here's my start...
> >=20
> >=20
> > class Point {
> >   int x;
> >   int y;
> >   ...
> > }
> >=20
> > aspect Observable {
> >  =20
> >   Display Point.observer;
> >=20
> >   void setObserver(Point p, Display d) { p.observer =3D d; }
> >=20
> >   Display getObserver(Point p) { return p.observer; }
> >=20
> > }
> >=20
> > Is this an example like you are talking about?
>=20
> Yes, although in our case Point would always be an empty=20
> class (e.g. no=20
> methods and no fields).
>=20
> In other words, if you instantiate a Point, or load a Point from a=20
> database, I do not want the Observable for that Point to be=20
> loaded/instantiated. It may only be loaded/instantiated when it is=20
> actually used for the first time. Just like lazy-loading semantics in=20
> EJB, or any other similar "object database" type system.
>=20
> /Rickard
>=20
> --=20
> Rickard =D6berg
> rickard@...
> Senselogic
>=20
> Got blog? I do. http://dreambean.com
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_06
> 1203_01/01
> _______________________________________________
> aopalliance-discuss mailing list
> aopalliance-discuss@...
> https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>=20

I'd like to try to stick with the smallest and simplest example possible to
identify this.  So I'm going back to Customer and logging, because there
is just the one aspect and the one class.  Let me know if this misses a
key point for you.

I hear you saying that you want the aspect methods to be "on the target class"
the same way the fields are.  That's easy to do, you just write:


aspect Logging {
	
	private byte[] Customer.log;    // these are big, so we delay initialization
	                                // till needed by having the getter methods
						  // do the initialization
			
	public byte[] Customer.getLog() {
	    if( log == null )
              log = new byte[100];
	    return log;
	}

}

I just changed the getter methods from methods on the aspect to methods on
Customer.

This still has the property that the log and honker fields (which we presume
to be big), won't be allocated until you want them to.  So I can pass around
Customer objects as much as I want, but only when I ask for the log or the
honker do I pay for them.

Does that do it?

>>>>> "Rickard" == Rickard Öberg <rickard@...> writes:

[...]

  Rickard> Now I can use a factory to create instances of MyId, which
  Rickard> really creates a dynamic proxy which handles invocations
  Rickard> and routes them to MyId, AImpl, BImpl or CImpl depending on
  Rickard> what method is invoked. *IF* a method to AImpl is performed
  Rickard> then the framework makes sure that an instance of AImpl is
  Rickard> loaded from the persistent store using the MyId instance as
  Rickard> key. BImpl and CImpl are still not loaded.

  Rickard> And this is the key here: that holding a reference to the
  Rickard> object and the state of the object being
  Rickard> instantiated/loaded is not the same thing. Just like in
  Rickard> EJB.

  Rickard> That is crucial. Without that feature any AOP framework is
  Rickard> no good, at least not for the kind of applications we're
  Rickard> using it for (i.e. EJB-ish).

  Rickard> Is it any more clear now?

It is perfectly clear to me.

But I have one question: why don't use an aspect which would intercept
methods and load the state of the object on demand ? I looks to me as
if your framework has a hardcoded persistence. Am I right ? 

-- 
Laurent Martelli                        http://jac.aopsys.com/
laurent@...                    http://www.bearteam.org/~laurent/

> *IF* a method to AImpl is performed then the framework makes sure that 
> an instance of AImpl is loaded from the persistent store using the 
> MyId instance as key. BImpl and CImpl are still not loaded.

But, is it always the case that the introductions should be lazy 
loaded? Couldn't this cause problems for some use cases (I can't think 
of any)?

Bob

Bob Lee wrote:

> Oooooo, and then, you could have a default pointcut built into the =20
> framework: apply the lazy-loading interceptor/introduction combination =
=20
> to objects that implement the IntroductionFactory interface and have =20
> the "lazyload" attribute (from the API perspective you'd use an "and" =20
> pointcut wrapping "instanceof" and "attribute" pointcuts). From then =20
> on, if you want your IntroductionFactory to lazy load, just slap on an =
=20
> @lazyload attribute!

Well, in the framework I wrote it always does this for all=20
introductions. It works great, both on client and server.

/Rickard

--=20
Rickard =D6berg
rickard@...
Senselogic

Got blog? I do. http://dreambean.com

Gregor Kiczales wrote:
> I believe the following program has the behavior that you want, except
> that you keep talking about an instance of Observable (i.e. Log) that
> doesn't exist, so I'm not sure.  But lets focus on the following simple
> code.
>=20
> What this code shows is that the byte array will not be allocated when
> instances of Customer are created. It will only be allocated when you
> call getLog. It does this using the standard simple mechanism Java uses
> for this, which is to omit the initializer in the field declaration.
>=20
> In what way is this not what you want?

There is one class that has all the fields. As I've already said, that's=20
not acceptable. I do not want all the introductions to be built together=20
into one class. Having lazyloading was just one small part of that.

Why isn't it acceptable? Because if the client (an applet) accesses an=20
object it is taken directly from the server-side caches and serialized=20
to the client. Even if fields are lazyloaded on the server it will be=20
serialized in its entirety to the client, and that is just way way way=20
too much data to transfer.

/Rickard

--=20
Rickard =D6berg
rickard@...
Senselogic

Got blog? I do. http://dreambean.com

Laurent Martelli wrote:
> It is perfectly clear to me.
>=20
> But I have one question: why don't use an aspect which would intercept
> methods and load the state of the object on demand ?=20

Sure, it can be done that way, but it doesn't make any sense. If you=20
don't have any caching pools it might make sense, but since I do it=20
doesn't.

I.e. the last thing that happens in an invocation to an introduction is=20
that a pool/cache is asked for an instance of the mixin. It is a lot=20
easier to just let the cache decide whether to load that mixin at that=20
point instead of doing an aspect that does it.

> I looks to me as
> if your framework has a hardcoded persistence. Am I right ?=20

It has "hardcoded" the idea of pools, which usually ties in to=20
persistence, yes. I tried to make the framework oblivious to the notion=20
of persistence at first but I couldn't make it work properly so I said=20
that fine, since this is how I'd always use it anyway, persistence is=20
known to the framework.

/Rickard

--=20
Rickard =D6berg
rickard@...
Senselogic

Got blog? I do. http://dreambean.com

Aha.  Now I see it.  This explanation

> Why isn't it acceptable? Because if the client (an applet) 
> accesses an object it is taken directly from the server-side caches and 
> serialized to the client. Even if fields are lazyloaded on the server it
> will be serialized in its entirety to the client, and that is just 
> way way way too much data to transfer.

was what I hadn't seen before.  The issue isn't lazy initialization
of the field values (on the server), the issue is lazy serialization
of fields (to the client).

Which you were probably saying all along, but I missed.

Let me think on that.

Gregor Kiczales wrote:
> I'd like to try to stick with the smallest and simplest example possibl=
e to
> identify this.  So I'm going back to Customer and logging, because ther=
e
> is just the one aspect and the one class.  Let me know if this misses a
> key point for you.
>=20
> I hear you saying that you want the aspect methods to be "on the target=
 class"
> the same way the fields are.  That's easy to do, you just write:
>=20
>=20
> aspect Logging {
> =09
> 	private byte[] Customer.log;    // these are big, so we delay initiali=
zation
> 	                                // till needed by having the getter me=
thods
> 						  // do the initialization
> 		=09
> 	public byte[] Customer.getLog() {
> 	    if( log =3D=3D null )
>               log =3D new byte[100];
> 	    return log;
> 	}
>=20
> }
>=20
> I just changed the getter methods from methods on the aspect to methods=
 on
> Customer.

What if I want to apply Logging to any class? How do you declare that?=20
The majority of mixins we've written can be, and are, applied to a=20
multitude of classes (all of which are id classes).

> This still has the property that the log and honker fields (which we pr=
esume
> to be big), won't be allocated until you want them to.  So I can pass a=
round
> Customer objects as much as I want, but only when I ask for the log or =
the
> honker do I pay for them.
>=20
> Does that do it?

Nope, because the data once loaded is still in one instance of a class.=20
The way our client-side "persistence manager" works is that it asks the=20
server-side object cache for an object (which in turn may cause a "real"=20
persistence manager to be invoked), and the result is sent back. But, if=20
I'm only using the Logging mixin on the client I only want the Logging=20
mixin to be sent. Anything else doesn't scale (believe me, we've tried=20
it, and sending 50Mb worth of data instead of 10k down a slow modem line=20
was a big deal). The above seems to imply that it's an "all or nothing"=20
approach.

Plus, the above is just the lazy-loading (and it's not even that because=20
it's only individual fields whereas usually the whole instance needs to=20
be primed with stored data). Once it's loaded you need to selectively be=20
able to *discard* individual mixins as well, if other data needs to be=20
loaded. Standard memory management principles, a la EJB again.

With all the examples you've shown me so far I am now convinced that my=20
initial conclusion still holds: AspectJ is not suitable for my=20
requirements, i.e. persistent, scalable, object-intensive systems. It=20
just does not focus on any of the important issues.

PLEASE note that I'm not saying that AspectJ is "bad", because I don't=20
believe in absolute "good" and "bad". All I'm saying is that for the=20
class of applications I'm working on it doesn't fit the requirements.

/Rickard

--=20
Rickard =D6berg
rickard@...
Senselogic

Got blog? I do. http://dreambean.com

Bob Lee wrote:
>> *IF* a method to AImpl is performed then the framework makes sure that=
=20
>> an instance of AImpl is loaded from the persistent store using the=20
>> MyId instance as key. BImpl and CImpl are still not loaded.
>=20
> But, is it always the case that the introductions should be lazy loaded=
?=20

Oh yes.

> Couldn't this cause problems for some use cases (I can't think of any)?

Sure, some cases cause the infamous "1+n finder problem" that EJB has,=20
i.e. when you're traversing a list or graph of objects it can cause a=20
lot of separate calls to the underlying persistence manager.

Which is why I invented the "loading policy" idea to deal with it, which=20
allows the client to specify declaratively the graph of objects that=20
he's interested in. When the first aspect is lazy loaded it eagerly=20
loads all other aspects according to the loading policy. It really has=20
worked out wonderfully for us and is an amazingly simple way to increase=20
performance.

/Rickard

--=20
Rickard =D6berg
rickard@...
Senselogic

Got blog? I do. http://dreambean.com

Gregor Kiczales wrote:

> Aha.  Now I see it.  This explanation
>=20
>>Why isn't it acceptable? Because if the client (an applet)=20
>>accesses an object it is taken directly from the server-side caches and=
=20
>>serialized to the client. Even if fields are lazyloaded on the server i=
t
>>will be serialized in its entirety to the client, and that is just=20
>>way way way too much data to transfer.
>=20
> was what I hadn't seen before.  The issue isn't lazy initialization
> of the field values (on the server), the issue is lazy serialization
> of fields (to the client).

It's both really, but yes that's a very big part of it. It also ties=20
back to the issue of evicting loaded persistent data in a timely manner.

/Rickard

--=20
Rickard =D6berg
rickard@...
Senselogic

Got blog? I do. http://dreambean.com

Gregor Kiczales wrote:
> 
> Which you were probably saying all along, but I missed.
> 
> Let me think on that.

Rickard made it kind of explicit in his blog, which is worth
reading:

AOP and pattern:
http://roller.anthonyeden.com/page/rickard/20020815?catname=Java

AOP, value objects, and lazy loading:
http://roller.anthonyeden.com/page/rickard/20020826?catname=Java

Rickard =D6berg wrote:

> Which is why I invented the "loading policy" idea to deal with it,=20
> which allows the client to specify declaratively the graph of objects=20
> that he's interested in. When the first aspect is lazy loaded it=20
> eagerly loads all other aspects according to the loading policy. It=20
> really has worked out wonderfully for us and is an amazingly simple=20
> way to increase performance.=20

Interesting...  EJB Relationship caching reinvented for aspects :-)

--=20
C=E9dric
http://beust.com/weblog

Cedric Beust wrote:
>> Which is why I invented the "loading policy" idea to deal with it,=20
>> which allows the client to specify declaratively the graph of objects=20
>> that he's interested in. When the first aspect is lazy loaded it=20
>> eagerly loads all other aspects according to the loading policy. It=20
>> really has worked out wonderfully for us and is an amazingly simple=20
>> way to increase performance.=20
>=20
> Interesting...  EJB Relationship caching reinvented for aspects :-)

Not really, since it's the *client* that determines the policy being=20
used, i.e. there are lots of different policies for different=20
relationships and such depending on who's calling, i.e. it depends on=20
the actual usecase and not the model.

I didn't know something similar was available for EJB relationships. Are=20
you saying there is?

/Rickard

--=20
Rickard =D6berg
rickard@...
Senselogic

Got blog? I do. http://dreambean.com

Rickard =D6berg wrote:

> Cedric Beust wrote:
>
>> Interesting...  EJB Relationship caching reinvented for aspects :-)
>
>
> Not really, since it's the *client* that determines the policy being=20
> used, i.e. there are lots of different policies for different=20
> relationships and such depending on who's calling, i.e. it depends on=20
> the actual usecase and not the model.
>
> I didn't know something similar was available for EJB relationships.=20
> Are you saying there is?=20

We do offer something called "relationship caching" which basically=20
instructs the container what fields should be eagerly loaded when=20
someone walks a relation.  Unless I misunderstood what you wrote, it's=20
the exact same idea you are using for policy loading.

It's a generalization of the idea of field groups.  A field group is=20
something like "if someone loads the column first_name, we should load=20
last_name as well".  Relationship caching extends this idea to other=20
beans that have a relationship with your current bean.

You can specify arbitrary sub-trees of any depth in this=20
relationship-caching tag (with a few exceptions, like when you hit the=20
many side of a relationship).  It's a very powerful feature and we have=20
observed impressive speed ups from customers using it.

It seems to me that's what your policy loading does, except that it's=20
generalized to advised (introduced) POJO's instead of EJB's.  Did I get=20
that right?

--=20
C=E9dric
http://beust.com/weblog

Cedric Beust wrote:
>> Not really, since it's the *client* that determines the policy being=20
>> used, i.e. there are lots of different policies for different=20
>> relationships and such depending on who's calling, i.e. it depends on=20
>> the actual usecase and not the model.
>>
>> I didn't know something similar was available for EJB relationships.=20
>> Are you saying there is?=20
>=20
> We do offer something called "relationship caching" which basically=20
> instructs the container what fields should be eagerly loaded when=20
> someone walks a relation.  Unless I misunderstood what you wrote, it's=20
> the exact same idea you are using for policy loading.
>=20
> It's a generalization of the idea of field groups.  A field group is=20
> something like "if someone loads the column first_name, we should load=20
> last_name as well".  Relationship caching extends this idea to other=20
> beans that have a relationship with your current bean.
>=20
> You can specify arbitrary sub-trees of any depth in this=20
> relationship-caching tag (with a few exceptions, like when you hit the=20
> many side of a relationship).  It's a very powerful feature and we have=
=20
> observed impressive speed ups from customers using it.
>=20
> It seems to me that's what your policy loading does, except that it's=20
> generalized to advised (introduced) POJO's instead of EJB's.  Did I get=
=20
> that right?

Not really. The strategy I talked about is the above plus that it's=20
determined by the *CLIENT*, i.e. the *CLIENT* says what eager loading to=20
be done programmatically before calling the beans with relationships=20
that should be eagerly loaded.

Like so:
http://roller.anthonyeden.com/page/rickard/20020826?catname=3DJava

Are you saying you have *CLIENT* specified eager loading too? From the=20
above description it doesn't seem so.

/Rickard

--=20
Rickard =D6berg
rickard@...
Senselogic

Got blog? I do. http://dreambean.com

--- Rickard_Öberg <rickard@...> skrev: >
Cedric Beust wrote:
> >> Not really, since it's the *client* that
> determines the policy being 
> >> used, i.e. there are lots of different policies
> for different 
> >> relationships and such depending on who's
> calling, i.e. it depends on 
> >> the actual usecase and not the model.
> >>
> >> I didn't know something similar was available for
> EJB relationships. 
> >> Are you saying there is? 
> > 
> > We do offer something called "relationship
> caching" which basically 
> > instructs the container what fields should be
> eagerly loaded when 
> > someone walks a relation.  Unless I misunderstood
> what you wrote, it's 
> > the exact same idea you are using for policy
> loading.
> > 
> > It's a generalization of the idea of field groups.
>  A field group is 
> > something like "if someone loads the column
> first_name, we should load 
> > last_name as well".  Relationship caching extends
> this idea to other 
> > beans that have a relationship with your current
> bean.
> > 
> > You can specify arbitrary sub-trees of any depth
> in this 
> > relationship-caching tag (with a few exceptions,
> like when you hit the 
> > many side of a relationship).  It's a very
> powerful feature and we have 
> > observed impressive speed ups from customers using
> it.
> > 
> > It seems to me that's what your policy loading
> does, except that it's 
> > generalized to advised (introduced) POJO's instead
> of EJB's.  Did I get 
> > that right?
> 
> Not really. The strategy I talked about is the above
> plus that it's 
> determined by the *CLIENT*, i.e. the *CLIENT* says
> what eager loading to 
> be done programmatically before calling the beans
> with relationships 
> that should be eagerly loaded.

Yes, this is quite an important difference, Cedric.
What Rickard has implemented is *dynamic*
load-policies while you in Weblogic only support
*static* load-policies.
This is a very important feature because the most
effective load-policy depends strictly on the what
use-case/scenario/transaction is currently executing
not on the static object-model. More over, from
Rickards description I understand it's also adaptive,
which means that the load-policies are adaptively
determined at runtime; a programmer can make
misstakes, never the program itself.
It's like adapative compilation in HotSpot and JRockit
it optimizes depending on how the code *executes* not
how it *looks*. 
I'm actually surprised no app-server or persistence
framework implement this, it's not very difficult to
implement and from what I can see it seems to be
massively useful and not to say easy to use. Stroke of
genius there Rickard!

> Like so:
>
http://roller.anthonyeden.com/page/rickard/20020826?catname=Java
> 
> Are you saying you have *CLIENT* specified eager
> loading too? From the 
> above description it doesn't seem so.
> 
> /Rickard
> 
> -- 
> Rickard Öberg
> rickard@...
> Senselogic
> 
> Got blog? I do. http://dreambean.com
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built
> ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are
> available now.
> Download today and enter to win an XBOX or Visual
> Studio .NET.
>
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> aopalliance-discuss mailing list
> aopalliance-discuss@...
>
https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss 

_____________________________________________________
Gå före i kön och få din sajt värderad på nolltid med Yahoo! Express
Se mer på: http://se.docs.yahoo.com/info/express/help/index.html

> (6) Supports multiple weave times. AspectJ is neutral on whether
>     weaving happens at pre-process, compile, post-process, load, 
>     JIT or runtime.  This neutrality is critical. Its why there


>     are serious JVM experts who are already thinking about JVM support for AspectJ.
 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Should the JVM support should be AspectJ-specific, or be actually 
'general' (allow other AOP systems to use it?).

If this is the case, how should this protocol between the AOP System and 
the JVM kernel look like?. I think it would be a pitty to hard-code a 
JVM feature which brings much more than point 6 (weaving time)
to a specific AOP tool (nothing against AspectJ, it's a great tool)

Regards,

Andrei




-- 
------------------------------------------------------------------------
Andrei Popovici
Institut fuer Informationssysteme
ETH Zurich
ETH Zentrum, 8092 Zurich
Tel: +41 1 632 7609
Fax: +41 1 632 1172