Re: Refactored JavaRpc - JSONObject from json.org

Hi Jean-Baptiste,

Am 01.07.2009 um 09:03 schrieb Jean-Baptiste BRIAUD -- Novlog:

>>> 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.

The serialization behaviour you need is quite different from what's  
currently done (JavaBean-based vs. attribute-based). I don't think it  
would be good idea to completely replace the existing approach.  
Instead, the algorithm should be configurable so that users can choose  
between JavaBean-based and attribute-based serialization (or plug in  
their own custom code).

Regards,

   Andreas J.

------------------------------------------------------------------------------