Community
Participate
Working Groups
This test case fails since aspectj 1.9.3 (1.9.4 also fails): https://github.com/subes/invesdwin-aspects/blob/master/invesdwin-aspects/src/test/java/de/invesdwin/aspects/internal/AssertNoSynchronizedScheduledAspectTest.java It works fine with aspectj 1.9.2. The expectation is that the exception thrown by the aspect arrives in the catch block. But instead a NullpointerException is thrown by aspectj without a clear stacktrace that indicates that it comes from aspectj. This happens with openjdk 1.8.0 8u212-b03 and openjdk 13 on ubuntu, thus should not be related to a specific java version. You can debug this directly in the linked github project as the test case should run anywhere. Just modify the supplied pom.xml to use the aspectj version you desire. The wrong exception caused by the regression is: java.lang.NullPointerException at de.invesdwin.aspects.internal.AssertNoSynchronizedScheduledAspectTest$ScheduledTestBean.scheduleSynchronized(AssertNoSynchronizedScheduledAspectTest.java:38) at de.invesdwin.aspects.internal.AssertNoSynchronizedScheduledAspectTest.testScheduled(AssertNoSynchronizedScheduledAspectTest.java:23) The desired exception is: java.lang.IllegalStateException: @Scheduled annotated method [public synchronized void de.invesdwin.aspects.internal.AssertNoSynchronizedScheduledAspectTest$ScheduledTestBean.scheduleSynchronized()] is synchronized. This can cause the scheduler to not trigger future schedules properly because he is blocked on a monitor. Please remove the synchronized modifier and use @SkipParallelExecution instead to fix this. at de.invesdwin.aspects.internal.AssertNoSynchronizedScheduledAspect.skipExecutionIfAlreadyRunning(AssertNoSynchronizedScheduledAspect.java:24) at de.invesdwin.aspects.internal.AssertNoSynchronizedScheduledAspectTest$ScheduledTestBean.scheduleSynchronized(AssertNoSynchronizedScheduledAspectTest.java:38)
I wonder if it relates to https://bugs.eclipse.org/bugs/show_bug.cgi?id=333274 which I was super nervous about doing.
Yep, it is exactly that. I knew I didn't have enough testcases for such a serious change. However, I did previously put guards on this change so you have to doing quite a few things to trigger the problem: - annotation style aspects - around advice - multiple around advices on the same thing - advice has to be subject to closure generation (not inlining) - one of those advice throws an exception| From the test program you attached (super helpful, thanks!), I can see these conditions are being triggered. I can see the double advice application: [AppClassLoader@75b84c92] weaveinfo Join point 'method-execution(void de.invesdwin.aspects.internal.AssertNoSynchronizedScheduledAspectTest$ScheduledTestBean.scheduleSynchronized())' in Type 'de.invesdwin.aspects.internal.AssertNoSynchronizedScheduledAspectTest$ScheduledTestBean' (AssertNoSynchronizedScheduledAspectTest.java:39) advised by around advice from 'de.invesdwin.aspects.internal.SkipParallelExecutionAspect' (SkipParallelExecutionAspect.java) [AppClassLoader@75b84c92] weaveinfo Join point 'method-execution(void de.invesdwin.aspects.internal.AssertNoSynchronizedScheduledAspectTest$ScheduledTestBean.scheduleSynchronized())' in Type 'de.invesdwin.aspects.internal.AssertNoSynchronizedScheduledAspectTest$ScheduledTestBean' (AssertNoSynchronizedScheduledAspectTest.java:39) advised by around advice from 'de.invesdwin.aspects.internal.AssertNoSynchronizedScheduledAspect' (AssertNoSynchronizedScheduledAspect.java) I have corrected the bytecode generation for the finally block to correctly rethrow the right exception. (Also added a testcase based on what this bug shows). All committed and pushed. The fixes are in 1.9.5.BUILD-SNAPSHOT builds, which you can get from: <repository> <id>repo.spring.io</id> <name>SpringSource snapshots</name> <url>http://repo.spring.io/snapshot</url> </repository>
When will 1.9.5 be released?
Nevermind, I just renamed the 1.9.5 snapshot release to be used in the mean time.
Sorry, I'm so busy getting ready for Spring One Platform. I would hope for 1.9.5 in October, i still need to look at supporting latest JDK and whatever other fixes I want to roll in.
