ClassProxy's for everything

[bill.burke]

The main problem I see is Serialization. Currently all AOP attached data and fields are not serialized across the wire. This is done on purpose because we want to support clients that are not using JBoss AOP. There are 2 things we can do for this. One, optionally provide a flag to make AOP fields non-transient, or use ClassProxy. AOP ClassProxy's are dynamically created classes that inherit from a base class and implement every public method of the base class to provide interceptor chains. They are used to provide interception for non-advised objects in AOP Remoting. They are serializable across the wire and retain their metadata. Actually. This ClassProxy construct is how will will support per instance introduction.

Well, why not use ClassProxy for everything? I have been seriously considering using ClassProxy for everything and never actually instrumenting the real class to add interceptions for methods or facilities to attach metadata. This alleviates all serializable problems. It also alleviates some of the line-number stack trace problems we are currently having

There are huge drawbacks to this which have prevented me from approaching AOP with proxies.

1. You would have to replaceNew with the generated ClassProxy class.

2. obj.getClass() would return the generated ClassProxy class. My feelin g is that this could break a lot of applications

3. In JBoss-AOP currently, reflection bypasses everything. So if you did a clazz.newInstnace or a constructor.newInstance() you wouldn't get an instance of the proxy.

My feeling is that direct class instrumentation is still the way to go.

[marc.fleury]

proxies are only necessary for remote imho,

everything else that is going to leave on the server should have pojo ref instrumentation through the Advisable interface. This is the major POJO point that all references will be instrumented

[marc.fleury]

let's discuss this.

So you overwrite the class new() in principle it means that you don't need to instrument the calling class.

If you need to instrument the calling class (as in field interception) then there is a dramatic drawback as we need to manage dependencies of classes being loaded.

I feel that functionalty ref vs proxy are the same except that

ref allows for transparent instrumentation of the tree of data introduced in cache. We can then do recursive inclusion of CacheAdvice and essentially dynamically instrument refs. You mentioned that the proxy approach would be a problem in Person.getAdress() but I don't see the point as you overwrite the "new of Adress()" as well. Maybe I am missing it?

I like the mental picture of instrumenting the references it allows of dynamic instrumentation. Say you insert something in cache, say you hold on to that reference outside the lookup of the cache. I guess they are the same and I fail to see a clear case when one is easier than the other.

I like the idea of instrumenting existing references :) that is what I call "introducing aspects" in a live reference and fuck what others think introduction is :)