| From | Sent On | Attachments |
|---|---|---|
| phon...@mobileandembedded.org | May 28, 2008 8:39 am | |
| phon...@mobileandembedded.org | May 28, 2008 10:47 am | |
| Hinkmond Wong | May 28, 2008 3:34 pm | |
| phon...@mobileandembedded.org | May 29, 2008 3:06 am | |
| phon...@mobileandembedded.org | May 29, 2008 9:29 am | |
| phon...@mobileandembedded.org | May 29, 2008 9:30 am | |
| Hinkmond Wong | May 29, 2008 12:55 pm | |
| phon...@mobileandembedded.org | May 31, 2008 9:08 am | |
| phon...@mobileandembedded.org | Jun 2, 2008 9:26 am | |
| phon...@mobileandembedded.org | Jun 2, 2008 9:38 am | |
| Hinkmond Wong | Jun 2, 2008 12:01 pm |
| Subject: | Re: running jade mobility with phoneME | |
|---|---|---|
| From: | Hinkmond Wong (hink...@dev.java.net) | |
| Date: | May 29, 2008 12:55:24 pm | |
| List: | net.java.dev.phoneme.advanced | |
Hi fpillone,
Here's a long-winded answer...
phon...@mobileandembedded.org wrote:
a simple make clean solved the system resources problem
(java.lang.OutOfMemoryError) even if i don't know why..
After having recompiled with the CVM_DEBUG=true, i still have the same error,
with no extra information :
Moving now to location : Main-Container
jade.core.mobility.AgentMobility: Error creating agent on destination container.
Abort transfer. A class was not found during de-serialization [nested
java.lang.ClassNotFoundException: [Ljava.lang.Object;]
Jade allows me to create java agents (~objects) , and make them move from one
computer to another one through serialization, maybe wasn't i clear about that.
At present, i am able to send an agent serialized on the PhoneME and
deserialized on the jdk1.4.2_16, but the bug occures when the agent is
deserialized on the PhoneME.
This is making more sense now. Thanks for the clarification about which JADE variation you are using and how you are using it for Agent Mobility. I see from your explanation about how you can de-serialize from phoneME to JDK 1.4.2_16, but cannot de-serialize the other way.
Did someone test the de-serialization ? I suppose it would be the next step for
me, or try with another VM, but i have some more critical tasks to do first.
Yes, de-serialization does work and has been tested on phoneME Advanced, but there are of course some requirements for using serialization between phoneME (Java ME) and Java SE.
When you serialize a Java object, the requirement is that the actual Java object being serialized must find all it's parent class hierarchy on the platform where it is being de-serialize.
So, for example, if you serialize an object which is an instance of the subclass of java.awt.Canvas, when you de-serialize that object it must find java.awt.Canvas (and in turn the entire parent hierarchy of java.awt.Canvas and all the other dependencies) on the target platform. And, it cannot be just a subset of java.awt.Canvas, it must be the same entire java.awt.Canvas class that was used to serialize the object (Serialization uses a hash of the methods and fields in the class to make a unique ID of the required parent hierarchy it must find on the platform).
In a nutshell, the problem I think you are seeing is that when you serialize from phoneME to Java SE 1.4.2, it is OK, since the entire parent class hierarchy of the object you are de-serializing is from phoneME which is a proper subset of Java SE 1.4.2.
However, the other way around, you are probably serializing a JADE object that drags in the parent class hierarchy of the Java SE 1.4.2 platform, which is a superset of the phoneME class hierarchy. That's a problem.
So, for example, the java.lang.Object that the Java SE 1.4.2 serialized Agent Mobility object depends upon is _not_ the same one that is found on phoneME.
It could look like this:
java.lang.Object (on Java SE 1.4.2) { method A; method B; method C; method D;
field A; }
java.lang.Object (on phoneME, subset of Java SE 1.4.2) { method A; method B; }
So, if you serialize an object that is a child of java.lang.Object from phoneME to Java SE 1.4.2, it's OK, since it will find both method A & B in the java.lang.Object in Java SE 1.4.2 when you de-serialize.
But, going the other way, if you serialize an object that is a child of java.lang.Object from Java SE 1.4.2, it is _not_ OK, since it will _not_ find methods C, D, or field A. You will get an exception thrown during de-serialization.
This is a compatibility problem that is solved in some cases by hardcoding (defining) a unique UID in some classes to override the hashing of the methods and fields. For example, you might find a line like this in some class files:
Throwable.java
--- ... /** use serialVersionUID from JDK 1.0.2 for interoperability */ private static final long serialVersionUID = -3042686055658047285L;
If you don't have the above in a class file, Serialization in Java will use a hash algorithm of the method and fields to create the UID.
And, that's the clash I think you are seeing.
The solution is not easy. It's up to the JADE software to do the right thing, like to hardcode a serialVersionUID in the object you are serializing or to make sure to serialize using the java.lang.Object from the PersonalJava/phoneME class hierarchy and not from Java SE 1.4.2.
Did you consult the docs for JADE to see if 2-way Agent Mobility should work? Or, possibly do they only mean that 1-way Agent Mobility should work?
If 2-way should work, maybe there is a special way you have to serialize when on Java SE 1.4.2 to make sure to serialize with a parent class hierarchy represented by the subset of the PersonalJava/phoneME platform. I'm not sure if they used a separate JAR file to represent that which you would point to during serialization, or if they have some other trick.
Let me know if you have more info on how JADE 2-way Agent Mobility should work with PersonalJava, since I'm thinking there may be more to their instructions when going from Java SE 1.4.2 to phoneME.
Also, are you building MIDP with phoneME? The docs you showed say PersonalJava (or phoneME Personal Profile) is required for Agent Mobility, not MIDP, so you shouldn't need themidp component or pcsl at all. To verify this part, can you send your make command line?
Thanks,
Hinkmond





