Hi Jean-Baptiste, Am 30.06.2009 um 09:46 schrieb Jean-Baptiste BRIAUD -- Novlog:
>> Anyway, why are you so keen on replacing the low-level JSON lib on >> the >> Java side? What's wrong with the one from json.org? I'd say "never >> touch a running system" in this case, except there's something >> seriously wrong or missing from the json.org version. >> > In fact, you are right ! > JavaRPC can be seen as 2 parts : > a. The RPC one : the servlet, the service and method call > management, ... > b. The JSON<->Java serialization. In fact, "b" consists of two layers internally: b1. The "high-level" serialization that converts arbitrary Java objects from and to "JSON representation objects" (like org.json.JSONObject and org.json.JSONArray). b2. The "low-level" JSON lib that can parse and generate JSON strings and provides "JSON representation objects". Of course, these layers may be intertwined in some libs. In the current Java RPC implementation in qooxdoo, they are separate: The low- level JSON stuff is handled by the json.org classes, and the high- level serialization is done in a custom implementation (RemoteCallUtils). > I'd like as a first step not to change anything and just use it but > only a. works perftly for me and I encountered issues with b. And those issues are ...? It would be nice if you could list the shortcomings of the json.org lib before discussing alternatives. Otherwise, there's no way to tell if any other lib would be a better choice. > The big plan, for me, is the following : > 1. Just use it and do things with it this summer > 2. Write test, say in september > 3. Think to refactor based on the experience of 1 with the security of > 2, say in october. > > So, maybe, I'll start again from sracth with pure JavaRPC and report > issue I have with b. here rather than trying to use it, refactor it at > the same time :-) > For now, I'm sure some issue I had was due to my lack of knowledge of > JavaRPC usage. See above. Something more concrete than just "issues" would be nice :-) > BTW, what about the transient Java keyword ? Are transient attributes > excluded from json serialization ? Just to make it clear, this point no longer concerns the low-level JSON lib (layer b2 above), but the higher level serialization of Java objects (layer b1). The current implementation doesn't work by looking at member variables. Instead, getters and setters according to the JavaBean convention are examined. And there's no way to tell whether an underlying member variable is transient by looking at its getter. It works this way in order to be able to transmit almost arbitrary Java objects. There are often classes that you cannot change (e.g. from 3rd party libs) and that are not serializable (and thus don't use the transient keyword for their attributes). On the other hand, almost every Java class adheres to the JavaBean convention. So by looking at the accessor methods, we usually can transmit these objects just fine (except for reference cycles, but this problem would also occur when looking at the attributes directly, and you can use the filter mechanism to avoid it). Regards, Andreas ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
