Dear Peter and Robert, the ULC coder infrastructure has built-in support for transferring Class object data, and so, there is no need to write a special ClassCoder for it. However, if you intend to "transfer" a class object, then there must also be a related coder registered for that class. The reason for this is that the ULC coder infrastructure supports type changes for objects which are transferred between client and server and vice versa (e.g. "java.awt.Dimension changes to com.ulcjava.base.application.util.Dimension" during the transfer). Consequently a transferred class object must also change during the transfer (in the latter case it would be: "java.awt.Dimension.class changes to com.ulcjava.base.application.util.Dimension.class")
Since ULC cannot determine exclusively from a given class object how the latter must change during transfer, it determines the respective class' coder and gets the associated peer class name. Therefore ULC tries to find the coder for your class "de.pds.CustomClass". I believe that this behaviour is a core "quality" of the coder infrastructure and so I am hesitant in classifying it as a bug. As a work around, you could do one of the following: - Register coders for the class objects you want to transfer... - Send strings instead of class objects! I guess you have a written a coder for a class which references some class object. In that coder you should simple write something like: out.writeUTF(clazz.getName()) instead of: out.writeObject(clazz) In the corresponding reader method you should then write: clazz = Class.forName(in.readUTF()) instead of: class = (Class) in.readObject(); Hope this helps, Daniel -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of ulc rbeeger Sent: Montag, 19. Juni 2006 12:35 To: [EMAIL PROTECTED] Subject: [ULC-developer] Problem with custom class coder Hi! In our application we have some methods on the client side that take a java.lang.Class object as a parameter. ULC 6.1 doesn't contain a coder for java.lang.Class, but since that's not really difficult we developed our own one: public class ClassCoder implements IStreamCoder { public String getPeerClassName() { return Class.class.getName(); } public void writeObject(IObjectOutputStream out, Object data) throws IOException { out.writeUTF(((Class) data).getName()); } public Object readObject(IObjectInputStream in) throws IOException { String className = in.readUTF(); Class result; try { result = Class.forName(className); } catch (ClassNotFoundException e) { throw new IOException("Die Klasse <" + className + "> konnte nicht gefunden und deshalb beim Einlesen nicht wieder hergestellt werden."); } return result; } } and registered it on both the client and server side coder registries: registry.registerCoder(Class.class, new ClassCoder()); The great problem here is that the coder is never used. In our first test where the classes used as parameters where classes like java.lang.String it seemed to work, but when we began using our own classes, it stopped working. When we now take a class "de.pds.CustomClass" ULC complains "No coder found for de.pds.CustomClass" and our ClassCoder isn't ever used. Why is ULC searching for a coder for de.pds.CustomClass. We aren't transfering objects of this class, only the class object itself. Cheers, Peter & Robert _______________________________________________ ULC-developer mailing list [email protected] http://lists.canoo.com/mailman/listinfo/ulc-developer
