ProfileService aspects are no longer being applied

[starksm64]

As I'm looking at the ProfileServiceUnitTestCase failures in more detail I see that none of the aspects registered in the bootstrap-repo-beans.xml AspectManager config are being applied to the deployers.

 <bean name="AspectManager" class="org.jboss.aop.deployers.AspectManagerJDK5">
 <constructor>
 <parameter><![CDATA[
 <aop>
 <aspect name="deployers" class="org.jboss.profileservice.aop.DeployerAspects"/>
 <bind pointcut="execution(* $instanceof{org.jboss.deployers.spi.deployer.Deployer}->prepareDeploy(..))">
 <advice name="invoke" aspect="deployers"/>
 </bind>
 <bind pointcut="execution(* $instanceof{org.jboss.deployers.spi.deployer.Deployer}->prepareUndeploy(..))">
 <advice name="invoke" aspect="deployers"/>
 </bind>
 <bind pointcut="execution(* $instanceof{org.jboss.deployers.spi.deployer.Deployer}->commitDeploy(..))">
 <advice name="invoke" aspect="deployers"/>
 </bind>
 <bind pointcut="execution(* $instanceof{org.jboss.deployers.spi.deployer.Deployer}->commitUndeploy(..))">
 <advice name="invoke" aspect="deployers"/>
 </bind>

 <aspect name="attachments" class="org.jboss.profileservice.aop.TrackingAdvice"/>
 <bind pointcut="execution(* $instanceof{org.jboss.deployers.spi.attachments.Attachments}->addAttachment(..))">
 <advice name="addAttachment" aspect="attachments"/>
 </bind>
 </aop>]]>
 </parameter>
 </constructor>
 <property name="enableLoadtimeWeaving">false</property>
 <!-- only relevant when EnableLoadtimeWeaving is true.
 When transformer is on, every loaded class gets
 transformed. If AOP can't find the class, then it
 throws an exception. Sometimes, classes may not have
 all the classes they reference. So, the Suppressing
 is needed. (i.e. Jboss cache in the default configuration -->
 <property name="suppressTransformationErrors">true</property>
 <property name="prune">true</property>
 <property name="include">org.jboss.test., org.jboss.injbossaop., org.jboss.deployers.</property>
 <property name="exclude">org.jboss.</property>
 <!-- This avoids instrumentation of hibernate cglib enhanced proxies
 <property name="ignore">*$$EnhancerByCGLIB$$*</property> -->
 <property name="optimized">true</property>
 <property name="verbose">false</property>
 <!--
 Available choices for this attribute are:
 org.jboss.aop.instrument.ClassicInstrumentor (default)
 org.jboss.aop.instrument.GeneratedAdvisorInstrumentor
 <property name="instrumentor">org.jboss.aop.instrument.ClassicInstrumentor</property>
 -->
 </bean>

Can you look into why this is now failing?

[starksm64]

Never mind. I did not realize the Deployer interface methods had changed that much. There are no longer any prepare/commit deploy/undeploy methods.

[starksm64]

That does bring up the question of whether there could be type checking on an aspect. If you could say that the pointcut expression must match the given interface signature this error could be reported.

[kabirkhan]

Just to decipher :-)

If the currently woven/proxied class matches the interface in a pointcut expression, and no methods mattch, you want some error to ne reported?

That is probably possible.

But maybe using an annotation might be more robust? AFAICR we do not currently support checking annotations inherited from interface methods, but if desired that should be pretty simple to add

[starksm64]

Just to decipher :-)

If the currently woven/proxied class matches the interface in a pointcut expression, and no methods match, you want some error to be reported?

Correct.

But maybe using an annotation might be more robust? AFAICR we do not currently support checking annotations inherited from interface methods, but if desired that should be pretty simple to add

Its not possible as in this case there are an unknown number of Deployers (the interface in the pointcut) and the Deployer interface is the only contract.

[kabirkhan]

execution(* $instanceof{org.jboss.deployers.spi.deployer.Deployer}->$implements{org.jboss.deployers.spi.deployer.Deployer}(..))

Will pick out ALL methods that exist in the Deployer interface, it might be more robust, but the aspect would need to do some filtering on methods to be advised, so maybe it's not much more useful in this case after all.