Re: [aspectj-users] Strange error after upgrade to AspectJ 1.6.8

[Andy Clement <andrew.clement@xxxxxxxxx>]

Could be onto something there Frank - I guess I need Hermann to try 1.6.9?

> - could load time weaving interfere somehow? Doesn't spring-aspects or the
> transactional support of Spring use loadtime weaving? I vaguely recall
> that some colleague told me he had to add aspectweaver.jar to some POM
> in that project. I'll check that tomorrow.

Yes, if using the spring library then LTW will also be in the mix.
There were some slight changes in what you have to specify in any
aop.xml files of your own if LTW but that would only apply if using
your own aspects for LTW (rather than spring-aspects) and they were
annotation style aspects.

>- of course, besides that the other question is why the older aspectj
> doesn't complain. Where there any changes in the name mangling of
> private ITD fields between 1.6.6 and 1.6.8

nothing changed in that respect in 1.6.8 - the big changes are in 1.6.9

Andy

On 20 July 2010 22:49, Frank Pavageau <frank.pavageau@xxxxxxxxx> wrote:
> Hi Andy, Hermann.
>
> It reminds me of my own
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=303924 which was fixed
> with 1.6.9: ITD, reweaving (since compile and load-time weaving were
> mentionned) & IncompatibleClassChangeError.
>
> Frank
>
> On Wed, Jul 21, 2010 at 12:35 AM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
>> Hi Hermann,
>>
>> The code looks fine.  I have seen something like that a while ago,
>> having to cast my mind back.  A similar situation is reported in
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=251151
>>
>> There it turned out to be a problem with two versions of a type being
>> around in the VM - one had been woven and one had not.
>>
>> But i guess you are going to tell me the classpath is completely
>> unchanged, all you have done is a recompile?  We could compare the
>> weaveinfo output between the two builds and check it is identical.
>>
>> Andy
>>
>> On 20 July 2010 15:13, prg@xxxxxxxxxxxxxxx <prg@xxxxxxxxxxxxxxx> wrote:
>>>
>>> Hello all,
>>>
>>> maybe someone can give me some hint as to what is broken here, or what to investigate
>>> further?
>>>
>>> In one of our larger J2EE Projects, I've just bumped the AspectJ version
>>> from 1.6.6 to 1.6.8. The Project is built with maven, compiled entirely with the AspectJ
>>> compiler and is deployed to a JBoss server, using Spring and Hibernate there (well, just
>>> it's generally a not so simple setup, as is the whole build process)
>>>
>>> Anyway, now we'll suddenly get an failure on deployment, at the point where
>>> the Hibernate SessionFactory should start up. Deeply buried in the stacktraces
>>> we see the following root cause
>>>
>>> Caused by: java.lang.reflect.InvocationTargetException
>>>     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>>>     at
>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:5
>>> 7)
>>>     at
>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImp
>>> l.java:45)
>>>     at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
>>>     at org.hibernate.engine.UnsavedValueFactory.instantiate(UnsavedValueFactory.java:45)
>>>     ... 151 more
>>> Caused by: java.lang.IncompatibleClassChangeError
>>>     at
>>> baag.boa.common.interfaces.DatenBeanGUIMethoden.ajc$interFieldInit$baag_boa_common_interfa
>>> ces_DatenBeanGUIMethoden$baag_boa_common_interfaces_DatenBean$beanTyp(DatenBeanGUIMethoden
>>> .aj:53)
>>>     at baag.boa.model.GDSettl.<init>(GDSettl.java:55)
>>>     ... 156 more
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>