JBossDeveloper

 

"alesj" wrote:
What exactly do you mean by "current filters are classname based"?
You cannot do globing (org.acme.foobar.*) like Adrian suggests?

You can do filtering on classnames, but what if you want to use aop for some instances and not for others?
Also, the current filters are there to turn off loadtime weaving for particular classes, they are not used by the proxies. This was a requirement from about 2 years ago since all "org.jboss." classes are excluded and people had to add their classes to the AspectManager.include attribute to get proxies created for them. There is a forum thread for that, and I'll post it here if I find it.

"alesj" wrote:

Kabir, what's the current search/matching mechanism?
Can it be made plugable?
Or how much would it take to improve that?

It is javacc based. Pointcut expressions are broken apart into their class + method/field names and signatures. For every candidate class for weaving /creating a proxy each field/method/constructor is compared against every pointcut (from the bindings). If annotations are used in the pointcut expressions it looks for those in the bytecode for the field/method/constructor and then hits the advisor annotation overrides + metadata.

Changing it would be a big job, but it could be made pluggable. Flavia did some stuff for her masters which we had planned to add to AOP later, which I think should speed this up. I'll let Flavia provide more info on that.

I don't know how easy these will be to do, but here are a few other initial ideas:

-The @DisableAop stuff can be made more fine-grained. It can still disable everything as it does, but since there will be less aop lifecycle bindings than normal bindings and aop lifecycle does not require a proxy and an advisor something like @DisableAop(lifecycle=true) could still check for dependencies for the aop lifecycle stuff and invoke those while avoiding the "real" aop bindings.

-If, for example, the messaging bindings should only be applicable to the messaging classes and not everything else. This would mean including something in the messaging jboss-aop.xml to indicate that these aspects should go into a child aop domain rather than the main aspectmanager, and some way to make sure that the classes would use that child domain. Apart from the bindings between classes and child aop domain, this would be similar to how the aop by scoped classloader stuff works.

-Some annotations could be made always checkable, e.g.

"jason" wrote:

I do agree that supporting various service annotations is useful

@JBossService
@interface SomeAnnotation{}

and bindings containing pointcut expressions with these annotations are always checked.

 

Kabir wrote:
Changing it would be a big job, but it could be made pluggable. Flavia did some stuff for her masters which we had planned to add to AOP later, which I think should speed this up. I'll let Flavia provide more info on that.

Yes, I did some stuff that optimizes the pointcut matching, replacing the matching by a search on a joinpoint graph. This replacement is performed only on dynamic aop operations, because it is cheaper to do the standard way (i.e., iterate through each joinpoint of a class) when loading new classes or when running aopc.

There is already a branch with my work integrated, but since this branch was created before we went 2.0.GA, I would need to perform more integration, so I could add this to JBoss AOP trunk.

 

"alesj" wrote:

"jason.greene@jboss.com" wrote:

but if the performance sucks as bad as this does, no one will use it.

Didn't you use this with PojoCache, but never noticed the bad performance? ;-)

Yes I inherited that choice, and I definitely noticed the problems, which is why I consider it's usage of AOP to be a failed experiment. Although we did tell people who cared about performance to use offline compilation when running under the AS. We also had all kinds of usability issues with it (most of problems reported where configuration errors, weaving issues, or stub compatibility problems).

The future replacement of PojoCache will take a saner JPA-like approach. BTW I don't mean to criticize JBossAOP, it's a good implementation of AOP. I just think we are using it solve problems that have way simpler and way faster solutions.

"jason.greene@jboss.com" wrote:

In general we should avoid expanding our usage of this until we know that the design is even fixable.

If Google can search a googol of entries in a split sec,
I don't see why we couldn't do the same for a handful of beans and aspects.

Kabir, what's the current search/matching mechanism?
Can it be made plugable?
Or how much would it take to improve that?

Idea of Lucene or Hadoop (on a single cpu) comes to my mind ... :-)
Or basically any decent BTrees impl should do.

But why go through all the trouble for something that is useful for at best 1% of our users, and then why penalize the common cases by default?

If someone actually wants to add an advice, and wants to do it with AOP expressions, and actually wants it to apply to our internal implementation beans (not sure if said person actually exists), why can't they just add it to some global registry.