Re: [aspectj-dev] InvalidClassException during load time weaving

[Choudary Kothapalli <choudary.kothapalli@xxxxxxxxx>]

Andy,

Here is my simple aspect:
----------
package mnj;
public aspect TestAspect {
	pointcut allExecutions():(execution(public * *.*(..))) &&
!within(mnj.TestAspect);

	Object around(): allExecutions(){
		System.out.println(thisJoinPoint);
		return proceed();
	}
}
---------
The test class is as follows:

package test;
import java.io.*;
public class Tester implements Serializable{	
	//private static final long serialVersionUID = 1L;
	
	public String data = "testData";
	
	public void write(String file) throws IOException{
		ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream(file));
		oos.writeObject(new Tester());
	}	
	public Tester read(String file) throws IOException, ClassNotFoundException{
		ObjectInputStream ois = new ObjectInputStream(new FileInputStream(file));
		return (Tester)ois.readObject();
	}	
	public static void main(String[] args) throws IOException,
ClassNotFoundException{
		String fileName = "data.ser";
		Tester tester = new Tester();
		//tester.write(fileName);
		tester.read(fileName);
	}
}
--------------
My scenario is as follows:
1. The application serializes Tester (before aspect weaving). Tester
does not define SUID.
2. Tester is weaved with TestAspect and deserialized.  It fails with
InvalidClassException. This is obviously because the Tester class
definitions differ (and generated SUIDs don't match) before and after
weaving.
3. If the SUID is explicitly defined, they match and there is no problem

As my product MaintainJ  is generic and should work with different
java runtimes, I cannot guess how the SUIDs are generated and avoid
affecting those classes. As I said in my first post, I can simply
avoid this problem by not weaving Tester class at all, but this
solution won't show the calls to those classes in the generated
sequence diagrams. Please let me know if you could think of any
workarounds.

Regards,
Choudary Kothapalli.

Here is the stack trace:
Exception in thread "main" java.io.InvalidClassException: test.Tester;
local class incompatible: stream classdesc serialVersionUID =
5068263196426222505, local class serialVersionUID = 489981860994650887
	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:546)
	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
	at test.Tester.read_aroundBody2(Tester.java:15)
	at test.Tester.read_aroundBody3$advice(Tester.java:109)
	at test.Tester.read(Tester.java:1)
	at test.Tester.main_aroundBody4(Tester.java:21)
	at test.Tester.main_aroundBody5$advice(Tester.java:109)
	at test.Tester.main(Tester.java:1)

On Sun, Jan 18, 2009 at 9:52 PM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
> Tricky problem.  Are you able to limit what your aspect does such that it
> doesn't affect the parts of the classes that contribute to the calculated
> SUID?  If you are just using advice and not intertype declarations, I can
> imagine it might be possible - but then it would depend on perclauses, use
> of around advice and whether that advice can be inlined.  Do you know which
> part of your aspect is affecting the SUID?
>
> cheers,
> Andy.
>
> 2009/1/16 Choudary Kothapalli <choudary.kothapalli@xxxxxxxxx>
>>
>> My product MaintainJ instruments an application using load time
>> weaving to capture the call trace and generate the sequence diagram. I
>> am having problems while deserializing classes that do not define a
>> SUID. The SUIDs of the original class and the weaved class are not
>> matching and InvalidClassException is thrown.
>>
>> Currently I suggest my users to exclude those classes, but some
>> applications serialize too many classes and this solution is not ideal
>> for them. Any ideas on how this problem can be solved?
>>
>> Thanks,
>> Choudary Kothapalli.
>> _______________________________________________
>> aspectj-dev mailing list
>> aspectj-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
>