Summary: | thisJoinPoint.getArgs() causes IncompatibleClassChangeError | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Rafael Chaves <chaves> | ||||||||
Component: | Compiler | Assignee: | Jim Hugunin <jim-aj> | ||||||||
Status: | RESOLVED FIXED | QA Contact: | |||||||||
Severity: | normal | ||||||||||
Priority: | P3 | ||||||||||
Version: | unspecified | ||||||||||
Target Milestone: | --- | ||||||||||
Hardware: | PC | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Attachments: |
|
Description
Rafael Chaves
2003-03-08 18:59:17 EST
Created attachment 3928 [details]
Java class
Created attachment 3929 [details]
First aspect
Created attachment 3930 [details]
Second aspect
Also, it is important to specify -1.4 to ajc or instead of the Error being thrown a VM crash may occur on scenario 1. This is fixed in the current tree. It was difficult to reproduce this error because Log1.aj didn't manifest the error as written. I had to comment out the call of thisJoinPoint.getArgs() from the second piece of after advice in order to see the error. This bug would have been easier to verify if you had just submitted a minimal test case that reproduced it. Believe you or not, I put a few hours cutting lines from my original aspects until I could understand what was generating the error and report a bug with a minimal test case. Also, I thought I had made explicit that for testing scenario 1 you should submit only the first aspect, and for testing scenario 2 you should delete the second advice in the first aspect and submit also the second aspect. But one thing I forgot to mention is that for scenario 2 you have to ensure Log1 is processed before Log2 by passing then explicitly in the command line. By the way, thanks for fixing it. It is a showstopper for my application. |