I think I've got the bypassing proxy stuff working now both with and without weaving.
I'm re-running some tests before committing. A summary of what I have done;
-AOP proxy creation/checks is disabled by default
-@EnableAopProxy on a bean forces it to go through the proxy checks
-@DisableAOP is deprecated, but will stil be checked if it is present and the new
annotations are not present
A few points:
-if a bean is not woven but has constructor aspects you want invoked, the bean needs the
@EnableAopProxy annotation
-If a bean's class is woven it can have aspects, so we will always check the AOP
dependencies for that bean. This will only happen if loadtime weaving was turned on (or
compile-time weaving was used) AND the bean matches some pointcuts, so it should not be an
issue in practice.
Once I've tidied up I'll commit to MC trunk, and try putting it into AS trunk
before moving on to replacing the mechanism for AOP lifecycle.
On 24 Dec 2009, at 12:29, Kabir Khan wrote:
I've made a start on this, but doubt I'll finish it before I
finish for Christmas. I am deprecating the @DisableAOP annotation. By default aop proxies
will be disabled, but can be enabled with @EnableAopProxy. Lifecycle callbacks will be
enabled by default (and I'll come up with a quicker way of determining if they should
apply), but can be disabled using the @DisableAopLifecycle annotation.
One issue that I need to look into is that there are a bunch of tests that run with
weaving enabled, so I need to see how they fare with this new setup. Since if they are
woven, aspects will apply, and if those aspects have dependencies we need those in
AOPDependencyBuilder.
On 24 Dec 2009, at 10:47, Ales Justin wrote:
>> +1, disable AOP wherever possible.
>
> I guess we can go the other way now, disabled by default + make
> lifecycle completely OO.
> We should then definitely see good improvement.
>
>> And I'd even dare say if you want @JMX, why not just
>> implement it the old fashion with MBean interfaces? It's simple and fast :-)
>
> You got that right, it's simple, probably too simple. ;-)
> I think one would still like to use the real power of POJO and IoC and
> just register it to MBeanServer for some simple admin/config.
>
> I dare to say I think you need to re-read this article :-)
> *
http://java.dzone.com/articles/a-look-inside-jboss-microconta-0
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development