Hi Jean-Baptiste, Am 15.06.2009 um 17:21 schrieb Jean-Baptiste BRIAUD -- Novlog:
> Why do I have to filter java.lang.Class or java.lang.reflect.Method ? "class" is filtered out in the default implementation to avoid unnecessary traffic and/or reference cycles. The root of the problem is that every Java object has a method "getClass" (which matches the JavaBean pattern). So without filtering, the RPC implementation would try to serialize the Class objects of all instances that are transmitted. And since java.lang.Class has lots of getXYZ() methods (some of them forming reference cycles IIRC), the JSON representation quickly explodes ... You don't have to filter java.lang.reflect.Method, at least not when you're transmitting simple objects. However, if there's a getXYZ() method in one of your objects that returns a java.lang.reflect.Method (or array thereof), then it should be filtered. Just look at the Java API documentation of Method so see why: There's stuff like getReturnType() that returns a Class. And regarding Class objects, see above ... Maybe I should provide some background info about the filtering mechanism. In general, when you try to convert Java objects to a String representation, there are two choices: 1.) Explicitly specify which properties get serialized. This requires some sort of meta data, e.g. the WSDL in case of web services. Or you can put up a requirement that every object needs to implement a specific serialization API (e.g. java.io.Serializable), which is also some kind of meta data. 2.) Serialize all properties by default. In this case, you have to provide a filter mechanism to avoid unnecessary traffic and reference cycles (see above). Both approaches have their pros and cons. qooxdoo's Java RPC implementation uses the second one to ease development and deployment. If you transmit simple objects, it works quite well. However, if you take existing, complicated business objects, you may have to adjust the filter. You could argue that the default filter list could be more extensive, but this would be a never-ending story: Many JDK classes are not easily serializable to a String, so you could end up with thousands of filter entries that would be checked before each transmission. You could also argue that only objects implementing java.io.Serializable should be transmitted, but that would be very annoying IMHO. Lots of objects in many libraries and existing applications are not implementing Serializable, even when they can be converted to JSON without issues. We could debate the different approaches all night long :-) If you don't agree with the one chosen in qooxdoos Java RPC implementation, take a look at the other Java RPC libraries out there. Maybe you can find one that suits your needs better (or mabye not - I don't know in detail how the different libs handle serialization). One last remark about the filtering: Even when your transmission works (no reference cycles), you should still take a look at the data stream. In many cases, you can reduce the size of the JSON string greatly by more aggressive filtering. If you have existing business objects that you'd like to transmit, there are probably tons of things that are of no interest to the client. Regards, Andreas J. ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
