[starksm64]

I reversed that change as it actually made the problems worse; none of the aspects were being applied. Why does the AspectManager need to depend on the mbeanServer/JMXKernel?

[kabirkhan]

The AspectManager bean needs to depend on the mbeanserver in order to register itself into JMX, and appying @JMX to that will not work since the @JMX aspect in turn will depend on the AspectManager service?

This was originally done to be able to run the AOP testsuite since that needs to turn on weaving with JMX. I see what you mean wrt the JBossServer being injected at the end.

I'll try creating a new wrapper bean for the JMX registration of the AspectManager so that the original AspectManager can start up in the same way as in the standalone tests then.

[kabirkhan]

I have removed the dependency from the AspectManager on JMXKernel.mbeanServer, and now the beans seem to start in the right order. Can you try the lifecycle stuff again from your original problem?

[starksm64]

It did not look like it worked at first, but then I saw you had updated some of the include attribute package names, and after updating that, org.jboss.deployers.spi.deployer.Deployer interception using an aop:lifecycle element works. I'll test out the others latter.

[kabirkhan]

Having to list the package names in the "include" attribute is a pain... The main intention for that is to not have to inspect every single loaded class when loadtime weaving is used.

I've not thought this through 100%, but there will be a lot less beans than loaded classes, so I am thinking of making this a bit more automatic by modifying the AOPDependencyBuilder to not use the include/exclude test. If the class is "excluded" but has aspects, then add this class to the list of "included" classes, so that when we come to the instantiate phase we get the aspects generated as expected.

Thoughts?

[starksm64]

Certainly aspects associated with beans should not need to also have packages associated with the aspect manager in its configuration. The mc/aop integration should take care of that.

[kabirkhan]

This requirement has been removed from the AOP/MC integration layer. Meaning the AspectManager bootstrap-beans.xml does not need to explicitly include classes that bean proxies should be created for:

 <bean name="AspectManager" class="org.jboss.aop.deployers.AspectManagerJDK5">
...
 <property name="include">org.jboss.test., org.jboss.injbossaop.</property>
 <property name="exclude">org.jboss.</property>

include/exclude now only have an effect for what classes to inspect if doing loadtime weaving.

A side effect of this is this error:

15:59:54,234 INFO [JMXIntroduction] Registered MBean jboss.ha:service=HASingletonDeployer,type=BarrierController
15:59:54,234 ERROR [AbstractKernelController] Error installing to Create: name=jboss.ha:service=HASingletonDeployer,type=BarrierController state=Configured
javax.management.MBeanException
 at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:184)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:165)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
 at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:186)
 at AOPContainerProxy$7.create(AOPContainerProxy$7.java)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:55)
 at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:108)
 at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
 at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:103)
 at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:145)
 at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197)
 at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136)
 at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
 at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:709)
 at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:430)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:540)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:474)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:274)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:177)
 at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:67)
 at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42)
 at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:56)
 at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52)
 at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:170)
 at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:592)
 at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:603)
 at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:476)
 at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:406)
 at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:367)
 at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:247)
 at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
 at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
 at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
 at org.jboss.Main.boot(Main.java:210)
 at org.jboss.Main$1.run(Main.java:508)
 at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.deployment.DeploymentException: Error during register: jboss.ha:service=HASingletonDeployer,type=BarrierController
 at org.jboss.deployment.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:52)
 at org.jboss.system.ServiceController.register(ServiceController.java:352)
 at org.jboss.system.ServiceController.create(ServiceController.java:375)
 at org.jboss.system.ServiceController.create(ServiceController.java:358)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
 ... 42 more
Caused by: java.lang.IllegalStateException: jboss.ha:service=HASingletonDeployer,type=BarrierController is already installed.
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:249)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:177)
 at org.jboss.system.ServiceController.doInstall(ServiceController.java:638)
 at org.jboss.system.ServiceController.register(ServiceController.java:344)
 ... 49 more

I assume that this bean was not one of the "included" ones earlier, so that the JMXIntroduction was never called for this bean. Now it does get called, so it pukes up when the ServiceMBeanSupport.create() method tries to call ServiceController.start()

[starksm64]

That is just a bad configuration of the jmx name as it is the same as the bean name:

 <bean class="org.jboss.system.BarrierController"
 name="jboss.ha:service=HASingletonDeployer,type=BarrierController">

 <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.ha:service=HASingletonDeployer,type=BarrierController", exposedInterface=org.jboss.system.BarrierControllerMBean.class, registerDirectly=true)</annotation>

I checked in a change to set the jmx name to jboss.ha:service=HASingletonDeployer,type=BarrierControllerMBean.

[starksm64]

Kabir, now none of the aspects configured via the AspectManager ctor xml are being applied, even when I add org.jboss.deployers to the include list. I have to specify the aspects via the aop:lifecycle-configure to get them to be applied.

There does not appear to be any support for specifying which method in an aspect to use via the aop:lifecycle-configure element. How would I map these aop.xml element to an aop:lifecycle-configure equivalent?

 <aspect name="track" class="org.jboss.profileservice.aop.TrackingAdvice"/>
 <bind pointcut="execution(* $instanceof{org.jboss.deployers.spi.attachments.Attachments}->addAttachment(..))">
 <advice name="addAttachment" aspect="track"/>
 </bind>
 <bind pointcut="execution(* $instanceof{org.jboss.deployers.spi.attachments.Attachments}->removeAttachment(..))">
 <advice name="removeAttachment" aspect="track"/>
 </bind>

[kabirkhan]

Kabir, now none of the aspects configured via the AspectManager ctor xml are being applied, even when I add org.jboss.deployers to the include list.

This has been fixed in AS trunk

There does not appear to be any support for specifying which method in an aspect to use via the aop:lifecycle-configure element. How would I map these aop.xml element to an aop:lifecycle-configure equivalent?

I should be able to add this over the weekend

[kabirkhan]

There does not appear to be any support for specifying which method in an aspect to use via the aop:lifecycle-configure element. How would I map these aop.xml element to an aop:lifecycle-configure equivalent?

This has been fixed, you can now do:

 <aop:lifecycle-configure xmlns:aop="urn:jboss:aop-beans:1.0"
 name="JMXLifecycle"
 class="org.jboss.test.microcontainer.support.TestAspect"
 classes="@org.jboss.aop.microcontainer.aspects.jmx.JMX"
 method="foo"
 pointcut="execution(* @org.jboss.aop.microcontainer.aspects.jmx.JMX->$implements{org.jboss.kernel.spi.dependency.KernelControllerContextAware}(..))">
 <property name="shouldInvoke">false</property>
 </aop:lifecycle-configure>

"method" specifies the aspect method