|
»
« Return to Thread: Refactored JavaRpc - JSONObject from json.org
Re: Refactored JavaRpc - JSONObject from json.org
by Jean-Baptiste BRIAUD -- Novlog
::
Rate this Message:
Hi Andreas,
Thanks for all your answers !
On Jun 30, 2009, at 12:21 , Andreas Junghans wrote:
> 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.
Don't worry, I'll use current implementation before changing
something :-) See below the "big plan".
>
>> 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).
>
That the thing. After some more thoughts about my needs and JavaRPC, I
can now explain why I'll need to add some behavior, at least in my
code using JavaRPC and later on inside JavaRPC if anyone is
interested : I can't rely only on that bean philosophy.
It doesn't fit my need to serialize any property that have a getter
and to keep OO and maintenance, I want that choice (serialize or not)
to be in the bean rather that in a global filter at servlet level.
Also, as I'm using Hibernate, the runtime introspection of my bean is
different than the source code because of AOP dynamic code injection
and I'll also have to handle that after the bean thing.
Basically, I need to use existing bean than I can modify but I can't
have new classes just for serialization.
I also want to declare which attribute will not be serializable on a
per attribute basis (not getter method basis).
I also don't want to rely on a global filtering mecanism at Servlet
level, I want to declare that in the bean because it depends of the
bean.
If there are some global rules, it is Ok to use a global property
filter in the servlet that would apply to all bean.
finally, I can't think to a simpler way to do that than using the
transient Java keyword.(not the @Transient JPA annotation, it is
different).
To implement that behavior without touching JavaRPC code, I used the
property filter at servlet level in a generic way : I explore the Java
metamodel, check if the given property of the given class is or not
transient and I remove it from the map if the property is transient.
I'm happy to have found a way (it is still under work) to use JavaRPC
with my own constraints.
I'll be more than happy to integrate it at JavaRPC level if it is
found usefull.
That way, I'll be able to focus on my project (where time is really
really short :-)
That way, I also use JavaRPC without changing it.
When all that will work properly, I also plan to write test and have a
performance check since all that metamodel use for bean that are not
evolving at runtime could be improved (at least for the code I'm
writing right now).
------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Thanks for all your answers !
On Jun 30, 2009, at 12:21 , Andreas Junghans wrote:
> 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.
Don't worry, I'll use current implementation before changing
something :-) See below the "big plan".
>
>> 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).
>
That the thing. After some more thoughts about my needs and JavaRPC, I
can now explain why I'll need to add some behavior, at least in my
code using JavaRPC and later on inside JavaRPC if anyone is
interested : I can't rely only on that bean philosophy.
It doesn't fit my need to serialize any property that have a getter
and to keep OO and maintenance, I want that choice (serialize or not)
to be in the bean rather that in a global filter at servlet level.
Also, as I'm using Hibernate, the runtime introspection of my bean is
different than the source code because of AOP dynamic code injection
and I'll also have to handle that after the bean thing.
Basically, I need to use existing bean than I can modify but I can't
have new classes just for serialization.
I also want to declare which attribute will not be serializable on a
per attribute basis (not getter method basis).
I also don't want to rely on a global filtering mecanism at Servlet
level, I want to declare that in the bean because it depends of the
bean.
If there are some global rules, it is Ok to use a global property
filter in the servlet that would apply to all bean.
finally, I can't think to a simpler way to do that than using the
transient Java keyword.(not the @Transient JPA annotation, it is
different).
To implement that behavior without touching JavaRPC code, I used the
property filter at servlet level in a generic way : I explore the Java
metamodel, check if the given property of the given class is or not
transient and I remove it from the map if the property is transient.
I'm happy to have found a way (it is still under work) to use JavaRPC
with my own constraints.
I'll be more than happy to integrate it at JavaRPC level if it is
found usefull.
That way, I'll be able to focus on my project (where time is really
really short :-)
That way, I also use JavaRPC without changing it.
When all that will work properly, I also plan to write test and have a
performance check since all that metamodel use for bean that are not
evolving at runtime could be improved (at least for the code I'm
writing right now).
------------------------------------------------------------------------------
_______________________________________________
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 |
