DR1 AOP goals

[bill.burke]

JBoss AOP has been criticized a lot. I thought I'd post what the goals of the DR1 release of JBoss AOP were. Here's what I wrote:

Agreed. Expanding pointcut definition has been the plan all along. As my post in late November suggested:

http://www.jboss.org/modules/bb/index.html?module=bb&op=viewtopic&t= we have only 2 joinpoints you can pointcut on. Classname and metatag. If the system-level aspects we wrote required a richer pointcut language, we would have implemented it. Yes, richer pointcuts are needed.

As I told Rickard, the goal of the DR1 release was to:

1) Find out if constuctor, field, and method interception on POJO's is doable. It is.

2) Provide Dynamic AOP. Hot deployment of XML descriptors. Interceptor definition on a per-instance level.

3) Provide a metadata facility that can
a) give you JSR-175 now, in the present
b) marry JSR-175 and AOP (They are a great match)
c) Provide fine-grained control. Interceptor behavior can be controlled on a fine-grained level as the context of the invocation

4) Most importantly, ship REAL WORLD aspects. These included:

a) J2EE a la carte: transaction demararcation and role-based security
b) Integration of our remoting framework with POJOs using AOP framework as the glue.
c) Transactional objects. Any pojo's state can be ACID with snapshot isolation. And this means the ENTIRE object graph. This uses Dynamic AOP.
d) Replicated cache. Transactional objects that are replicated across an entire cluster. This uses Dynamic AOP.

It is our feeling that an AOP framework alone cannot compete against something like AspectJ since they are at least a year ahead of any AOP framework.

Until there is more work done defining the AOP methodology, the average application developer will have trouble adopting any type of AOP framework. This is where pre-packaged aspects like JBoss AOP come in.

Anyways there is only so much one person can code, document, and release in a limited time frame. When you are working against a deadline, you must draw a line someplace. I think we were right to focus on the aspects themselves and let these aspects drive the framework.

It would be nice if you all posted your comments on our development forum rather than on your own blogs. Otherwise I have to search for it or have somebody email me saying somebody commented on it.

Please comment on our development forums. I pay attention to them, I don't always remember to go look at somebody elses blog.

Bill

[shareme]

Bill no need to apollogize for the goals..

If you read my Rcikard' comments alreqdy you know that there are both logic and data hole sin Rickard's technical points.. :)

I for one am satisifed with the goals that have been met so far and I am starting to explore how to integrate JBoss with my Mobile game server concepts and achitecture this fall and spring of 2004..

I look forward to exploring more JBoss AOP that the group defines..

AOP in the way JBoss is implementing it is important to me on my gameGO proejct becasue in Mobile game serving environments you have to serve the gaem controller on the server side as their is not enough bandwidth/processing power on the handset side ..

Thus, even using Jini you have serialization of bojects and thus the desire to use every trick in the book to reduce the performanc ehit of that object creation..using AOP in JBOss allows me to address that issue in a new interesting ways that solve the problem..without the added bloat of EJB..

[juhalindfors]

> So we have only 2 joinpoints you can pointcut on.
> Classname and metatag. If the system-level aspects
> we wrote required a richer pointcut language, we
> would have implemented it. Yes, richer pointcuts are
> needed.

Why are join points beyond meta tag required? By richer pointcut language do you mean adding boolean logic for meta tags when declaring pointcuts? If so, I'd agree.

If you mean adding some type of pattern matching language then I'm not convinced it is needed or even a good idea.

-- Juha

[bill.burke]

> > So we have only 2 joinpoints you can pointcut on.
> > Classname and metatag. If the system-level aspects
> > we wrote required a richer pointcut language, we
> > would have implemented it. Yes, richer pointcuts
> are
> > needed.
>
> Why are join points beyond meta tag required? By
> richer pointcut language do you mean adding boolean
> logic for meta tags when declaring pointcuts? If so,
> I'd agree.
>
> If you mean adding some type of pattern matching
> language then I'm not convinced it is needed or even
> a good idea.
>

I am currently adding
- per-method, field, and constructor pointcuts so that we can have individual chains for each
- Instanceof. If class instanceof another class, apply the pointcut

Later on I want to add:
- caller pointcut. only intercept on a specific class that invokes a method on a different class.
- expressions within instanceof, class, methodName, etc... so that you can do
instanceof="!org.jboss.aop.Interceptor && java.io.Serializable"

Can you expand on your concerns with examples?

BIll

[juhalindfors]

> I am currently adding
> - per-method, field, and constructor pointcuts so
> that we can have individual chains for each

Ok, so this isn't supported via meta tags yet? I cannot add tags per method or field yet?

> Can you expand on your concerns with examples?

Anything that binds aspects based on object structure seems like a bad idea to me since the framework doesn't include a compiler support. Changing field names, method names and signature etc. will break my app. so I would definitely avoid those, even class names to a certain extent.

Binding aspect based on a meta tag doesn't suffer from the same problem -- because it is meta data. The aspect binding is not coupled with any implementation detail of my object structure. Separation of concerns.

-- Juha

[juhalindfors]

> Later on I want to add:
> - caller pointcut. only intercept on a specific
> class that invokes a method on a different class.

Yes this was one of the most interesting features in AspectJ for me. What is the plan to implement this?


> - expressions within instanceof, class, methodName,
> etc... so that you can do

boolean expressions yes, although I would still not use them in conjuction to anything that directly references my object structure, with metatags yes.

-- Juha

[bill.burke]

> > I am currently adding
> > - per-method, field, and constructor pointcuts so
> > that we can have individual chains for each
>
> Ok, so this isn't supported via meta tags yet? I
> cannot add tags per method or field yet?
>

Just added this on Friday. It will be in the DR2 release July 1st.

> > Can you expand on your concerns with examples?
>
> Anything that binds aspects based on object structure
> seems like a bad idea to me since the framework
> doesn't include a compiler support. Changing field
> names, method names and signature etc. will break my
> app. so I would definitely avoid those, even class
> names to a certain extent.
>
> Binding aspect based on a meta tag doesn't suffer
> from the same problem -- because it is meta data. The
> aspect binding is not coupled with any implementation
> detail of my object structure. Separation of
> concerns.
>
> -- Juha
>

You make an interesting point. I guess the type safety that AspectJ boasts of is really just an illusion when you're dealing with any type of regular expression. Interestingly, all the aspects we've written so far in JBoss 4 are either metatag driven(transactions, security) or dynamically added(remoting, caching).

Bill

[bill.burke]

> > Later on I want to add:
> > - caller pointcut. only intercept on a specific
> > class that invokes a method on a different class.
>
> Yes this was one of the most interesting features in
> AspectJ for me. What is the plan to implement this?
>

Javassist is amazing. Check out:

javassist.expr.ExprEditor

What's cool about the ExprEditor is that you can practically intercept anything i think.


Of course this type of functionality goes against your earlier worries of type safety.

Bill