Comment 1 Andrew Clement 2011-01-28 12:23:01 EST

I suspect this is the same kind of problem as for 333572.  Something has a bad serialized form. I'm having a lot of trouble determining what it is though.  I create an aspect based on what you supplied and it just compiles fine for me (I stubbed out everything it referenced) - are you able to construct a complete little program that fails as you describe?  I really want to get this bug squashed...

Comment 2 Anis Moussa 2011-01-28 17:01:03 EST

(In reply to comment #1)
> I suspect this is the same kind of problem as for 333572.  Something has a bad
> serialized form. I'm having a lot of trouble determining what it is though.  I
> create an aspect based on what you supplied and it just compiles fine for me (I
> stubbed out everything it referenced) - are you able to construct a complete
> little program that fails as you describe?  I really want to get this bug
> squashed...

I will be develop something asap and post it !
Thanks and regards
Anis

Comment 3 Anis Moussa 2011-01-31 04:30:45 EST

 Unfortunalty a simple test case did not reproduce the issue :( I tried making a simple Aspect with a simple class where the pointcut could be matched with no success :(

I can add few more details , because in my application, I reproduce every time the compile time weaver starts .

My point cut is the following :
	@Pointcut("execution(@javax.annotation.security.RolesAllowed * *(..))")

and it's an Around advice .

the error thrown is :

java.lang.NegativeArraySizeException
at org.aspectj.weaver.patterns.TypePatternList.read(TypePatternList.java:490)
at org.aspectj.weaver.patterns.ThrowsPattern.read(ThrowsPattern.java:120)
at org.aspectj.weaver.patterns.SignaturePattern.read(SignaturePattern.java:913)
at org.aspectj.weaver.patterns.KindedPointcut.read(KindedPointcut.java:335)
at org.aspectj.weaver.patterns.Pointcut.read(Pointcut.java:279)
at org.aspectj.weaver.Resolved ... Job.run(AutoBuildJob.java:242)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

what is surprising , is when I use the Maven aspectj weaver (with aspectjrt.jar ) , it runs without errors on the same code .

it's too difficult for me to narrow my code because it's a big project. But it's a straight forward error .

here is my simple aspect :
@Aspect
public class AnnotationAspect
{

	@Around("AtRolesAllowed()")
	public Object aroundGAtRolesAllowed(ProceedingJoinPoint joinPoint) throws Throwable
	{
		System.out.println("AtRolesAllowed Matched ");

		return joinPoint.proceed();

	}

	/**
	 * Matches the execution of any method with the Secured annotation.
	 */
	@Pointcut("execution(@javax.annotation.security.RolesAllowed * *(..))")
	public void AtRolesAllowed()
	{}


and here is a target method :
@RolesAllowed("ROLE_USER")
	public void sayHello(){
		System.out.println("I'm Secured");
	}

please let me know if I can help more , I will continue narrowing down the issue

Comment 4 Anis Moussa 2011-01-31 10:36:26 EST

Ok , I think I found out what's the issue 

This AJDT  uses version 1.6.10 of Aspectjrt and Aspectjweaver. while the aspectj-maven-plugin from org.codehaus.mojo uses the version 1.6.7 from the same .

the exception happens actually when you build your project with Maven ,so ur aspects and the weaved classes uses 1.6.7 ,and once you edit your target classes(then AJDT applies). So the problem is reduced to a conflict between AspectJweaver/compiler .

we tested a patched version of aspectj-maven-plugin  that uses 1.6.10 version of Aspectjrt/weaver, and the issue is gone.

please notice that 1.3 version of aspectj-maven-plugin is the latest.

what you recommend ?

Comment 5 Andrew Clement 2011-01-31 16:07:29 EST

Hi. I can imagine that, yes, it is a cross version problem - otherwise many of the existing tests in our testsuite would be failing.

I've tried taking the snippets of code discussed here, building them with 1.6.7 then feeding them to 1.6.10 but they just work, no errors.  Something you could try is taking the broken aspect library (built with 1.6.7) and feeding it to AspectJ 1.6.10 on the command line, outside of AJDT, to see if that fails.  A simple

ajc -1.5 -inpath library.jar -outjar dump.jar

should trigger the problem if it is a serialization issue.

If that fails, it would be great if you could give me either the aspect class file from the jar, or if that is too much maybe I can explain how to extract the attribute data from the class file and you can give me that.  You wouldn't have to attach any of it here, you can email it me privately.

I really want to get this resolved, but really hard to find the cause if I can't recreate.

Comment 6 Anis Moussa 2011-02-01 04:15:05 EST

Hi Andy 

Ok , at first, please take in consideration that the issue is reduced to a conflict between aspectj compiler versions ,I have a test case that reproduce this issue and I'm attaching it to this bug .

the test case  consist on 2 parts :

1- the aspect library :testcase-aspectj

It's a eclipse project,build by Maven , that contains one aspect Jsr250AnnotationBasedSecurityAspect.

This aspect is build using the aspectj-maven-plugin version 1.3 (refer to the Pom file ).This version of the plugin comes with the aspectjrt.jar version 1.6.7.


2-a simple lib SimpleLib:

This is an AspectJ eclipse project , with only one java class where actually the aspect defined in 1 could match(SimpleClass.java)
 . the AspectJ Build path (AJDT Plugin) is pointing to the jar file defined in 1. 
to reproduce the issue , simply edit the SimpleClass.java and save. you will expect a popup ( I will also attach it ),which an exception.

the AJDT as we know is using the aspectjrt.jar version 1.6.10.


I will attach every thing to this defect .


Regards
Anis

Comment 7 Anis Moussa 2011-02-01 04:20:59 EST

Created attachment 188031 [details]
TestCase

You can simply import the projects in eclipse

Comment 8 Torben Knerr 2011-02-01 11:33:24 EST

Hi Andy,

please find attached an additional test case that is based on Maven only (i.e. can be reproduced even without AJDT).

It shows that aspects compiled with 1.6.7 can not be read by the weaver/compiler version 1.6.10. From what we experienced this happens only when the annotation-based syntax (@Aspect, @Pointcut) is used.

So most likely it is an aspectj problem that propagates to (latest version of) AJDT as it uses aspectj 1.6.10.

Test case is set up as follows:
* test-aspect-aj contains a simple aspect defined in "original" aspectj syntax (.aj file). It is compiled with aspectj 1.6.7 (see pom.xml).
* test-aspect-anno contains the same aspect but with annotation-based syntax. It is compiled with aspectj 1.6.7 (see pom.xml).
* test-aspect-client contains a Main class with a simple method that is to be advised. This project is weaved with aspectj 1.6.10 (see pom.xml)

To reproduce the problem with the annotation-based syntax:
1) build test-aspect-anno with "mvn clean install"
2) build test-aspect-client with "mvn clean install"

==> during the build of test-aspect-client you will get the following exception:

[----8<----- snip ----8<-----]
abort ABORT -- (BCException) malformed org.aspectj.weaver.EffectiveSignature attribute (length:92)java.io.EOFException
when batch building BuildConfig[null] #Files=1 AopXmls=#0

malformed org.aspectj.weaver.EffectiveSignature attribute (length:92)java.io.EOFException
when batch building BuildConfig[null] #Files=1 AopXmls=#0

org.aspectj.weaver.BCException: malformed org.aspectj.weaver.EffectiveSignature attribute (length:92)java.io.EOFException
when batch building BuildConfig[null] #Files=1 AopXmls=#0

	at org.aspectj.weaver.AjAttribute.read(AjAttribute.java:139)
	at org.aspectj.weaver.bcel.Utility.readAjAttributes(Utility.java:101)
...
[----8<----- snap ----8<-----]

If you switch the commented lines in test-aspect-anno/src/main/java/com/foo/TestAspect.java and repeat the steps above you can also produce a NegativeArraySizeException:

[----8<----- snip ----8<-----]
java.lang.NegativeArraySizeException
	at org.aspectj.weaver.patterns.TypePatternList.read(TypePatternList.java:490)
	at org.aspectj.weaver.patterns.ThrowsPattern.read(ThrowsPattern.java:120)
	at org.aspectj.weaver.patterns.SignaturePattern.read(SignaturePattern.java:913)
	at org.aspectj.weaver.patterns.KindedPointcut.read(KindedPointcut.java:335)
	at org.aspectj.weaver.patterns.Pointcut.read(Pointcut.java:279) 
...
[----8<----- snap ----8<-----]


To verify that it works with the .aj syntax:
1) build test-aspect-aj with "mvn clean install"
2) in test-aspect-client/pom.xml change the two dependencies from test-aspect-anno to test-aspect-aj
3) build test-aspect-client with "mvn clean install"

==> this should work as expected - no issues there.

Best regards,
Anis & Torben

Comment 9 Torben Knerr 2011-02-01 11:35:33 EST

Created attachment 188061 [details]
contains test case to reproduce the problem with Maven

attached test case mentioned in previous comment

Comment 10 Andrew Clement 2011-02-01 17:11:24 EST

Excellent testcase, thanks!

As I play with it I see the EffectiveSignature problem and the NegativeArraySizeException.  I can see that it is rather more subtle than a bug in the serialized form, which is why I was having such trouble recreating it.

The issue relates to how we determine what version of serialized attributes we are looking for.  1.6.7 uses version 6, AspectJ 1.6.9 (and onwards) use version 7. The version number is stashed as an attribute in the aspect alongside the other attributes.

The problems occur when we attempt to interpret the data expecting the wrong version.  Annotation style aspects have a slightly different codepath here because there are also annotations to look at.  I can see where AspectJ is forgetting what version it was using, and then defaulting to the latest (7).  We then attempt to load a version 6 EffectiveSignatureAttribute - this fails as indicated.  The first fix is to remember the version properly - this has been a bug for a long time, but because the format hasn't changed for the particular kinds of thing you find in an annotation style aspect hasn't changed, it didn't matter.

What complicates the situation is that during weaving we also create new ones and deserialize them.  Created ones always use the latest format.  This can lead to a situation where we have some old ones (6s) and some new ones (7s) - and we need to deserialize them appropriately.

Comment 11 Andrew Clement 2011-02-01 19:41:49 EST

I think I've fixed it.  Fixes should be in an AJDT dev build later today.

Comment 12 Torben Knerr 2011-02-02 03:58:54 EST

Hi Andy, 

thanks for the quick help! I will try the latest dev build once it is out and let you know if we can verify the fix.

What confuses me a bit is the fact that the AspectJ compiler produces different bytecode for the aspectj (.aj) and annotation-based syntax. With my limited knowledge about AspectJ I believed that these are just two different syntaxes for expressing the same thing, so my assumption was that the outcome of the compilation should be the same.

Can you rectify my understanding about this?


I also have some general questions concerning compatibility between aspectj compiler/weaver versions. From what I have read on http://www.eclipse.org/aspectj/doc/released/devguide/compatibility.html my understanding is as follows:
 * it should be perfectly possible to mix aspect libraries compiled with different versions of ajc as long as ajc version >= 1.2.1 and as long as at weaving time we use a weaver with equal or higher version
 * the compatibility guarantees above apply for both syntaxes, .aj-style and annotation-style (=> i.e. this issue describes an unexpected behaviour)
 * it will be problematic if we mix code that has been weaved with different versions of the weaver (=> thus it is a "best practice" to lazily weave dependent .jars, i.e. we weave them when we use them instead of when we build them, isn't it?)


Would you personally prefer one syntax over the other with respect to backwards compatibility? :-)

Thanks a lot and best regards,
Torben

Comment 13 Anis Moussa 2011-02-02 04:13:26 EST

Hi Andy , sorry for all those questions ,

I would like also to add to Torben's questions,one more :):

Is there a short term plan or an ongoing improvement request , in order toe expose the setting of the AspectJ compiler/weaver version outside AJDT ?

means , can I as a User , change the aspectj compiler version used by AJDT like it's the case for the maven aspectj plugin ?

are you aware of any plan to integrate Aspectj compiler within the JVM some day ? 


Thanks in advance for your help 
Anis

Comment 14 Torben Knerr 2011-02-02 07:19:44 EST

Hi Andy,

a bit more input:

We just tested the latest AJDT dev build (2.1.2.e36x-20110201-1700) against the testcase above (annotation-based aspects compiled with aspectjtools 1.6.7 via Maven) and the error message no longer pops up.

However, as soon as we change TestAspect.java slighty so that @Pointcut and @Around are separated we are facing the same errors again.

Updated test case:

@Aspect
public class TestAspect
{
	private TestDep	dep	= new TestDep();

	@Pointcut("execution(@com.foo.ProfiledMethod * *(..))")
	public void profiledMethodPointcut() {
	}
	
	@Around("profiledMethodPointcut()")
	public Object profileMe(ProceedingJoinPoint thisJoinPoint) throws Throwable
	{
		// XXX: causes (BCException) malformed org.aspectj.weaver.EffectiveSignature attribute
		return dep.invoke(thisJoinPoint);
		
		// XXX: causes NegativeArraySizeException
		// return thisJoinPoint.proceed();
	}
}


This should again produce the errors, even with the latest AJDT dev build.

What we also noticed is that alone the presence of the @Pointcut annotation seems to cause the problem, even if it is not referenced in the @Around annotation:

@Aspect
public class TestAspect
{
	private TestDep	dep	= new TestDep();

	@Pointcut("execution(@com.foo.ProfiledMethod * *(..))")
	public void profiledMethodPointcut() {
	}
	
	@Around("execution(@com.foo.ProfiledMethod * *(..))")
	public Object profileMe(ProceedingJoinPoint thisJoinPoint) throws Throwable
	{
		// XXX: causes (BCException) malformed org.aspectj.weaver.EffectiveSignature attribute
		return dep.invoke(thisJoinPoint);
		
		// XXX: causes NegativeArraySizeException
		// return thisJoinPoint.proceed();
	}
}

When commenting out the @Pointcut annotation the error does not occur. 


Best regards,
Anis, Torben

Comment 15 Andrew Clement 2011-02-02 12:14:02 EST

> What confuses me a bit is the fact that the AspectJ compiler produces different
> bytecode for the aspectj (.aj) and annotation-based syntax. With my limited
> knowledge about AspectJ I believed that these are just two different syntaxes
> for expressing the same thing, so my assumption was that the outcome of the
> compilation should be the same.
>
> Can you rectify my understanding about this?

They are two different syntaxes for the same thing, but the classfiles are going
to look different.  In the annotation style case there will be annotations stored
in the classfile which you will not find for code style.  In the initial problem here
we find the 'extra' processing that is done for annotation style is tripping over
something in the attributes - code style would not have gone looking for
annotations as it didn't need to, but if it had gone looking it also would have
tripped over the same thing.

I did not write the annotation style support, but there are many places here and
there where the compiler/weaver do different things for annotation style
aspects.  You shouldn't have to worry about that though and just choose the
syntax that makes sense in your setup - I would always choose code style,
probably due to familiarity, but if you want to go with annotation style
it is fully supported.


> I also have some general questions concerning compatibility between aspectj
> compiler/weaver versions. From what I have read on
> http://www.eclipse.org/aspectj/doc/released/devguide/compatibility.html my
> understanding is as follows:
>  * it should be perfectly possible to mix aspect libraries compiled with
> different versions of ajc as long as ajc version >= 1.2.1 and as long as at
> weaving time we use a weaver with equal or higher version

Yes, that is right.
 
> * the compatibility guarantees above apply for both syntaxes, .aj-style and
> annotation-style (=> i.e. this issue describes an unexpected behaviour)

Yes, this is a critical bug that you have hit, hence me wanting to urgently fix it.
1.6.10 will always be broken, but I hope we can get it resolved in 1.6.11.
Unfortunately the bug isn't where I would have expected, in the serialized
form, it is a more fundamental issue that has been in forever, where some parts
of the weaver were never correctly handling the compatibility support, it just
never turned up before because I hadn't changed the serialized form for
some of the basic entities.  So even though it was making a mistake in what
level of attribute to unpack, both forms were the same until 1.6.9.

> * it will be problematic if we mix code that has been weaved with different
> versions of the weaver (=> thus it is a "best practice" to lazily weave
> dependent .jars, i.e. we weave them when we use them instead of when we build
> them, isn't it?)

No, shouldn't be a problem.  I often see this setup.  Spring libraries built with
1.6.8 being used in a Spring Roo app built with 1.6.9 and then all load time woven
using Spring Insight running with 1.6.10.

> Would you personally prefer one syntax over the other with respect to backwards
> compatibility? :-)

In general I prefer code style - you can do more.  You can't do itds nicely in
annotation style.   I also know the code style implementation better because
I have written most of it.  But in terms of backwards compatibility, it shouldn't matter
which you choose.

> is there a short term plan or an ongoing improvement request , in order toe
> expose the setting of the AspectJ compiler/weaver version outside AJDT ?

There is an open enhancement request somewhere for this on bugzilla.  I doubt
we'll do it in the short term though.  The interface between AJ and AJDT does
change over time and having to also manage compatibility of that across versions
would be painful (allowing some users to put an old ASPECTJ into a recent AJDT).
I would say if you want to run with an old AspectJ, use an old AJDT, the old
releases should still be accessible.  It is unfortunate you have hit this compatibility
problem, but normally I'd say you wouldn't notice that AJDT includes dev builds
of AspectJ.

> means , can I as a User , change the aspectj compiler version used by AJDT like
> it's the case for the maven aspectj plugin ?

The jars in the eclipse aspectj bundles are just a repackaging of those shipped
in an AspectJ distribution, building them is just a matter of running a packaging
script.  However, with the interfaces moving, AJDT will likely break horribly.
(For example yesterday I extended the AJ API to allow AJDT to do more, if
you put a backlevel AJ in now, AJDT will crash when trying to call those APIs).

I'll take a look at your latest failure findings.

Comment 16 Anis Moussa 2011-02-02 12:32:17 EST

Thanks Andy for your feedback ! 

We spent all the day digging into this , and I deeply believe that the issue is limited to the presence of @Pointcut annotation within the Aspect.

It actually also surprises me that,even in the case of *not* using the pointcut in the @Around advice would make the test to fail. and simply commenting the Pointcut  definition makes it work :)


I would add also for your information a summury of Today tests with the latest dev build :

1-Aspect with @Pointcut , and the Advice return thisJoinPoint.proceed(); ==>Works

2-Aspect with @Pointcut,and the Advice return dep.invoke(thisJoinPoint);  ==>fails  with (BCException) malformed org.aspectj.weaver.EffectiveSignature attribute.



3-Aspect  without @Pointcut,keeping the point cut declaration inthere,and the Advice return dep.invoke(thisJoinPoint);==>fails with (BCException) malformed
org.aspectj.weaver.EffectiveSignature attribute.


4-Aspect  without @Pointcut,commenting the point cut declaration inthere,and the Advice return dep.invoke(thisJoinPoint);==>works


5-Aspect  without @Pointcut,keeping the point cut declaration inthere,and the Advice return thisJoinPoint.proceed(); ==>fails with NegativeArraySizeException.


6-Aspect  without @Pointcut,commenting the point cut declaration inthere,and the Advice return thisJoinPoint.proceed(); ==>works



Thanks and Regards

Torben and Anis

Comment 17 Andrew Clement 2011-02-02 14:19:03 EST

Torben, Anis, thanks so much for your work on this :)

> It actually also surprises me that,even in the case of *not* using the pointcut
> in the @Around advice would make the test to fail. and simply commenting the
> Pointcut  definition makes it work :)

The existence of an @Pointcut annotation means that will be in the classfile, regardless of whether it is used.  The entire classfile is processed (loaded) by the weaver, which means all the attributes are deserialized, regardless of which pieces you may or may  not use.  

I've created new testcases for scenarios 2,3,5 from your list.

I've also fixed them.  The problem was this bit of code:

if (processedPointcut) {
  // FIXME asc should check we aren't adding multiple versions...
  // will do once I get the tests passing again...
  struct.ajAttributes.add(new AjAttribute.WeaverVersionInfo());
  struct.ajAttributes.addAll(mstruct.ajAttributes);
}

As you can see it is only triggered if there is a pointcut in the classfile.  And the comment I left in there eludes to something I hadn't yet gotten around to...  In fact what happens is that we correctly build a structure marked as version 6 serialized form (AspectJ 1.6.7), that rogue add() above then splats over it with the 'default' WeaverVersion, which is currently 7 (AspectJ 1.6.9 and above).  If we attempt to unpack an EffectiveSignature attribute written with 6 but assuming it is 7, the exception occurs.  The NegativeArraySizeException is down to the same root cause, incorrectly sticking the version. So the fix is actually to comment out that add() line - since the work I did yesterday is now getting the version right.

This will be in a dev build of AspectJ and AJDT today.

Comment 18 Torben Knerr 2011-02-03 02:50:31 EST

Hi Andy,

thanks for the close and extensive feedback!

(In reply to comment #15)
> > * it will be problematic if we mix code that has been weaved with different
> > versions of the weaver (=> thus it is a "best practice" to lazily weave
> > dependent .jars, i.e. we weave them when we use them instead of when we build
> > them, isn't it?)
> 
> No, shouldn't be a problem.  I often see this setup.  Spring libraries built
> with
> 1.6.8 being used in a Spring Roo app built with 1.6.9 and then all load time
> woven
> using Spring Insight running with 1.6.10.

When writing this I had "eager compile-time weaving" (not sure how to better call this) in mind, i.e. my assumption was that if a.jar is woven with 1.3.0 and b.jar is woven with 1.5.0 and c.jar (which has a.jar and b.jar as dependencies) uses aspectjrt 1.6.9, would that still be compatible?

With "lazy compile-time weaving" the approach would be to not weave a.jar and b.jar at all until they are used in the client application. This lets you decide as late as possible (i.e. when you put everything together in c.jar) which version of the weaver and aspectjrt to use. Is this documented as kind of a "best practice" somewhere?
 
Best regards,
Torben

Comment 19 Anis Moussa 2011-02-03 04:46:49 EST

Hi Andy 

Thanks a lot for the build. we did few tests  this morning , and Yes all issues seem to be fixed! Thanks a lot for your effort.
we now look forward for the release version .

we also have discussed the issue with the 
"lazy compile-time weaving",and we believe that this is the safest way to have a consistent weaving infrastructure . Is this statement true ?
PS:We have seen in the news about the snow storm in the US,I hope every thing is alright , we had a part of it here in Germany :)
Thanks 
Anis

Comment 20 Andrew Clement 2011-02-03 11:59:15 EST

> When writing this I had "eager compile-time weaving" (not sure how 
> to better call this) in mind, i.e. my assumption was that if a.jar 
> is woven with 1.3.0 and b.jar is woven with 1.5.0 and c.jar 
> (which has a.jar and b.jar as dependencies) uses aspectjrt 
> 1.6.9, would that still be compatible?

Yes.  The runtime is always backwards compatible - we never remove function from the runtime (so the old woven code will always find what it is looking for).

> With "lazy compile-time weaving" the approach would be to not
> weave a.jar and b.jar at all until they are used in the client
> application. This lets you decide as late as possible (i.e.
> when you put everything together in c.jar) which version of 
> the weaver and aspectjrt to use. Is this documented as kind of
> a "best practice" somewhere?

We don't really put requirements on that as any combination should be OK.  Of course the most recent weavers are faster, produce more optimal code and use any new features that have been added to the runtime - so using the latest if you
can is always a good approach.

> Thanks a lot for the build. we did few tests  this morning , 
> and Yes all issues seem to be fixed! Thanks a lot for your 
> effort. We now look forward for the release version.

Thanks for the feedback, I'm glad we appear to have gotten to
the bottom of this.

> we also have discussed the issue with the "lazy compile-time 
> weaving",and we believe that this is the safest way to have
> a consistent weaving infrastructure . Is this statement true ?

It is unfortunate you hit the bugs this issue uncovered - if
you want to avoid possibly hitting them in the future then
weaving as late as possible and trying to do it with the same
version across the board will hopefully achieve that.  But I
hope we don't have any more issues like this one :)

> PS:We have seen in the news about the snow storm in the US,
> I hope every thing is alright , we had a part of it here in
> Germany :)

Luckily, I'm in Vancouver and we're only suffering the usual rain
rather than snow.

Comment 21 Anis Moussa 2011-02-03 12:04:45 EST

Thanks a lot Andy for your feedback !
I may be more curious, is there an ETA for the next release ? because we are basing our solution with this key fix that you just made, and we would like to have a little bit of  forecast :) 

one more question, does AJDT/AspectJ compiler have an SVN repository , so I can have a look at the fixes ,just out of curiosity :)

Thanks and Regards
Anis

Comment 22 Andrew Clement 2011-02-03 12:20:42 EST

> I may be more curious, is there an ETA for the next release ? because we are
> basing our solution with this key fix that you just made, and we would like to
> have a little bit of  forecast :) 

1.6.11 is targetted for end of March, maybe a bit earlier, around EclipseCon.

> one more question, does AJDT/AspectJ compiler have an SVN repository , so I can
> have a look at the fixes ,just out of curiosity :)

We have a cvs repo, but no nice fisheye on it.  The browser interface is here:
http://dev.eclipse.org/viewcvs/viewvc.cgi/org.aspectj/modules/?root=Tools_Project
whilst the instructions are checking out the source are here:
http://www.eclipse.org/aspectj/doc/released/faq.php#q:buildingsource

The fixes were quite small though.  For example, for the one above, the code went from:

if (processedPointcut) {
  // FIXME asc should check we aren't adding multiple versions...
  // will do once I get the tests passing again...
  struct.ajAttributes.add(new AjAttribute.WeaverVersionInfo());
  struct.ajAttributes.addAll(mstruct.ajAttributes);
}

to

if (processedPointcut) {
  struct.ajAttributes.addAll(mstruct.ajAttributes);
}

All the changes for this bug just related to making sure we remembered the version that was used to build the attributes so that we had the correct expectations when deserializing them.

Comment 23 Anis Moussa 2011-02-03 15:14:05 EST

Thanks Andy , I will then look at the sources .

We look forward for the release and we will survive with what we have at the moment(since an aj code styte is perfectly working for us at the moment).

we also use an m2eclipse extra plugin that detect whenever a aspect library is defined in the pom file, it appends automatically the AspectJ Build path,but still not deepely tested !

Thanks again for your help
Anis