Community
Participate
Working Groups
I am attempting to wrap all method calls to a given class A with a simple around advice using the following aspect definition. import com.systemsunion.spikes.deadlock.SQLDeadlock; aspect NoRetry { pointcut sqldeadlock(SQLDeadlock bean) : target(bean) && call (public void *(..)); after(SQLDeadlock bean) returning : sqldeadlock(bean) { System.out.println("Should not reach"); } before(SQLDeadlock bean) : sqldeadlock(bean) { System.out.println("About to deadlock"); } void around(SQLDeadlock bean) : sqldeadlock(bean) { System.out.println("Begin"); proceed(bean); System.out.println("End"); } } The interface SQLDeadlock (actually the RemoteInterface of an EJB) declares a couple of methods deadlock() and deadlock(Object), calls to either of which I wish to wrap with the advice. Obviously, this is just a first step, but the above aspect which compiles OK fails at runtime with the following stack trace. java.lang.NoSuchMethodError: org.aspectj.runtime.internal.AroundClosure.<init>([Ljava/lang/Object;)V at com.systemsunion.spikes.deadlock.TestCallEJBs$AjcClosure1.<init>(TestCallEJBs.java) at com.systemsunion.spikes.deadlock.TestCallEJBs.main(TestCallEJBs.java:29) Exception in thread "main" Process terminated with exit code 1 Complaining it can't find the constructor for AroundClosure. I took a look at the source code for AroundClosure and the only constructor takes no arguments - hence the failure - but interestingly it seems it used to take an array of objects which were assigned to its instance variable state as this code is commented out in the current source code for AroundClosure. If I remove the elipses in the call join-point then the around advice works fine, whether I am matching the zero argument or the one argument version of the method. This looks like a bug to me, but I am a newby to AOP and AspectJ so am quite willing to accept that I may have done something stupid. If so, I would be grateful for any pointers as to how I should have specified my aspect. I am using the 1.1 release, but also tried it under a CVS checkout from last night with the same result. The definition of the SQLDeadlock interface is here /* * Generated file - Do not edit! */ package com.systemsunion.spikes.deadlock; /** * Remote interface for SQLDeadlock. */ public interface SQLDeadlock extends javax.ejb.EJBObject { public void deadlock( java.lang.Object ignored ) throws com.systemsunion.framework.common.util.locator.ServiceLocatorException, javax.transaction.SystemException, javax.transaction.RollbackException, java.rmi.RemoteException; public void deadlock( ) throws com.systemsunion.framework.common.util.locator.ServiceLocatorException, javax.transaction.SystemException, javax.transaction.RollbackException, java.rmi.RemoteException; } and of the test class TestCallEJBs is here /** * (c) Copyright Systems Union Group, Ltd. 2003, All Rights Reserved. */ package com.systemsunion.spikes.deadlock; import com.systemsunion.framework.common.util.locator.ServiceLocator; import com.systemsunion.framework.common.util.log.LogConfig; import com.systemsunion.framework.common.security.client.TestCaseLoginHelper; public class TestCallEJBs { public static void main(String[] args) { try { LogConfig.init(); TestCaseLoginHelper.login(); SQLDeadlockHome sqlHome = (SQLDeadlockHome) ServiceLocator.getHome(SQLDeadlockHome.class); SQLDeadlockNoRetryHome sqlNoRetryHome = (SQLDeadlockNoRetryHome) ServiceLocator.getHome(SQLDeadlockNoRetryHome.class); SQLDeadlock sql = sqlHome.create(); SQLDeadlockNoRetry sqlNoRetry = sqlNoRetryHome.create(); sql.deadlock(); sqlNoRetry.deadlock(); } catch (Exception e) { e.printStackTrace(); } } }
I think this is a configuration error. I'm pretty sure that you're using a 1.0.x version of aspectjrt.jar with code that is compiled with the 1.1 compiler. The 1.0.x version of AroundClosure only has a single zero-arg constructor as you describe below. The 1.1 version of AroundClosure has TWO constructors. One that's zero-arg, but another one that takes an Object[]. My guess is that you have an old version of aspectjrt.jar on your classpath that is being chosen over the one from 1.1. If you can't easily resolve this issue, then I recommend that you ask about this configuration issue on aspectj- users where you might find someone with more specific experience in the ejb space. If you're convinced this isn't just a configuration error, then please submit a self-contained test case that can be used to reproduce the bug.