|
»
« Return to Thread: Refactored JavaRpc - JSONObject from json.org
Re: Refactored JavaRpc - JSONObject from json.org
by andreas.junghans
::
Rate this Message:
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
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
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
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
« Return to Thread: Refactored JavaRpc - JSONObject from json.org
| Free embeddable forum powered by Nabble | Forum Help |
