Refactored JavaRpc - JSONObject from json.org

[Jean-Baptiste BRIAUD -- Novlog]

Hi,

I can see that current JavaRPC is using JSONObject form json.org.
Few questions :

1. Apparently, this is delivered from json.org directly with Java  
source text files. What about version ? No CVS/SVN ? No Jar files ?  
Should I copy/past again from json.org in order to update this code ?

2. Should I check other libs or does JSONObject still the right  
choice ? Anyone to give me some historic background about this choice  
like known pro/cons, ... things I should know before jumping, ...

3. Current JavaRPC users, did you find any lack in the Java <-> JSON I  
should know ?

Thanks !

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[andreas.junghans]

Hi Jean-Baptiste,

Am 29.06.2009 um 11:09 schrieb Jean-Baptiste BRIAUD -- Novlog:

> I can see that current JavaRPC is using JSONObject form json.org.
> Few questions :
>
> 1. Apparently, this is delivered from json.org directly with Java
> source text files. What about version ? No CVS/SVN ? No Jar files ?
> Should I copy/past again from json.org in order to update this code ?

In the beginning, the code was synced with the json.org version once  
in a while. However, it has also been extended for Date support (look  
for "// AJ" in the code), so you can't just blindly copy the latest  
version. It would be a good idea to put this into a new package to  
make it clear that the implementation has been modified. Of course, I  
should have done this from the start, sorry about that :-(

> 2. Should I check other libs or does JSONObject still the right
> choice ? Anyone to give me some historic background about this choice
> like known pro/cons, ... things I should know before jumping, ...

There hasn't been any evaluation. json.org as the "primary JSON site"  
seemed like a logical choice, and the implementation works well  
enough. Of course you're free to evaluate alternatives, but keep in  
mind that Date support would have to be added to whatever library you  
choose. There has been some discussion about keeping qooxdoo's special  
date handling or not - see http://bugzilla.qooxdoo.org/show_bug.cgi?id=1400 
   Maybe it's time to revisit that. But anyway, I think sticking to  
the modified json.org implementation is fine for now (there are enough  
other things to do ...).

> 3. Current JavaRPC users, did you find any lack in the Java <-> JSON I
> should know ?

Not that I know of.

Regards,

   Andreas J.


------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Jean-Baptiste BRIAUD -- Novlog]

About other lib, I was thinking about http://code.google.com/p/google-gson/
Any feedback ?

I didn't read anything about Date restriction in gson.
I understand that qooxdoo Date serialization is special but all good  
implementation of JSON serializer allow for custom serialization/
deserialization, so we could make qooxdoo Date serialization case  
optional.

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[andreas.junghans]

Hi Jean-Baptiste,

Am 29.06.2009 um 14:11 schrieb Jean-Baptiste BRIAUD -- Novlog:

> About other lib, I was thinking about http://code.google.com/p/google-gson/
> Any feedback ?

Never used it, so I'm not able to comment.

> I didn't read anything about Date restriction in gson.
> I understand that qooxdoo Date serialization is special but all good
> implementation of JSON serializer allow for custom serialization/
> deserialization, so we could make qooxdoo Date serialization case
> optional.

Careful with that. Usually, custom (de)serialization is achieved via  
additional attributes ("hints") in the transmitted JSON data. However,  
the Date support in qooxdoo works via direct "new Date(...)"  
expressions. I haven't looked at the Google lib you mentioned, but I  
seriously doubt that this kind of syntax can be plugged in easily.  
(Again, we might not want to keep the qooxdoo date support, but that's  
a separate discussion, see bug #1400.)

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.

Regards,

   Andreas


------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Jean-Baptiste BRIAUD -- Novlog]

On Jun 29, 2009, at 18:13 , Andreas Junghans wrote:

> Hi Jean-Baptiste,
Hi Andreas,

[CUT]
>
> 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.

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.

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.

BTW, what about the transient Java keyword ? Are transient attributes  
excluded from json serialization ?

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[andreas.junghans]

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

[Jean-Baptiste BRIAUD -- Novlog]

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

[andreas.junghans]

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.


------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Jean-Baptiste BRIAUD -- Novlog]

On Jul 1, 2009, at 13:28 , Andreas Junghans wrote:

[CUT]
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).

Yes, I fully agree.

Inspired from Hibernate, an annotation at class (bean) level may be used to choose.

Currently, I'm no more trying to filter the map but to build it since beanutils use the bean-based way. This is currently super ineficient since the map is still calculated the bean-based way but I don't care.

First, I want to make it work and only after, I'll think about what to improve.

Here is what can be done with Hibernate as an analogy :

@Entity

@AccessType("field")

public class MyBean { ... }

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

_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[andreas.junghans]

Hi Jean-Baptiste,

Am 01.07.2009 um 14:33 schrieb Jean-Baptiste BRIAUD -- Novlog:

> On Jul 1, 2009, at 13:28 , Andreas Junghans wrote:
>> [CUT]
>> 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).
>
> Yes, I fully agree.
>
> Inspired from Hibernate, an annotation at class (bean) level may be  
> used to choose.

I'm not sure that's a good idea. IMHO the approach should be  
configurable on the RPC level, not (only) inside the classes that are  
serialized. After all, there may be cases where you want to use  
attribute-based serialization, but without a chance to modify the  
class in question (so you cannot add the necessary annotions).  
Instead, I think it should work something like this:

rpcLayer.setSerializer(new net.sf.qooxdoo.rpc.JavaBeanSerializer());

or

rpcLayer.setSerializer(new net.sf.qooxdoo.rpc.AttributeSerializer());

or

rpcLayer.setSerializer(new my.custom.Serializer());

Of course, the interface of the serializer classes would need to be  
specified first. Maybe Michael's branch already facilitates something  
like this?

> Currently, I'm no more trying to filter the map but to build it  
> since beanutils use the bean-based way. This is currently super  
> ineficient since the map is still calculated the bean-based way but  
> I don't care.
> First, I want to make it work and only after, I'll think about what  
> to improve.
>
> Here is what can be done with Hibernate as an analogy :
>
> @Entity
> @AccessType("field")
> public class MyBean { ... }

I'm fine with the annotation approach for controlling the details.  
However, the fundamental serialization algorithm should be  
configurable on a more global level. The annotations can then be used  
by the (de)serializer for fine-grained control. What do you think?

Regards,

   Andreas J.


------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Jean-Baptiste BRIAUD -- Novlog]

On Jul 1, 2009, at 16:42 , Andreas Junghans wrote:

[CUT]
>
> I'm fine with the annotation approach for controlling the details.
> However, the fundamental serialization algorithm should be
> configurable on a more global level. The annotations can then be used
> by the (de)serializer for fine-grained control. What do you think?

Both levels are needed depending on contraints JavaRPC user have.
If one can't change beans, things can be adjusted from outside only.
If one can change or ammend the bean, OO approach is in favor of  
adjusting serialization behavior from withint the bean.
The idea in that case is not to push business information (like  
exclude this or that) at global level.

Finally, both levels seem usefull depending on usage.

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Jean-Baptiste BRIAUD -- Novlog]

Hi,

As I said later on, here is a quick feedback of my use of JavaRPC.
I used the HEAD of SVN contrib.
I have some specific needs : reuse some POJO that I can modify. In  
other words, the same POJO class are used not only by JavaRPC but also  
by some other things.
Basically, the only problem I was facing was the choice of what  
property I wanted to exclude and what properties I wanted serialise  
throw JavaRPC.
I would love to do that with annotation or introspection using  
transient Java keyword but this would involve too much JavaRPC  
refactoring.

Finally, I managed to stay in the current design : JavaBean  
specification using Apache implementation to detect accessors.
To reach my goal I simply added a new convention and a new method for  
filtering properties.
Rather than taking any accessors, I take only those who meet the  
namming convention.
The convention :
Let's consider a property p.
One "normal" accessor would be getP() and the other would be setP(P p).
The convention for an accessor to be serialized throw JavaRPC is :
set_ser_P() and get_ser_P(P p)

So, the filter from Java to RPC is to keep only _ser_ accessors and  
then to remove the _ser_ from Apache bean introspection Map so after  
the operation all look like normal accessor.
Then, for the other way around, from RPC to Java, all accessors are  
rennamed by adding back _ser_ so the corresponding method on the POJO  
accessors will be used to set back the values.

This allow me to use accessors with the JavaBean design starting from  
persistent POJO that are stored from fields annotations (not from  
accessors).

The only method I had to add to RemoteCallUtils API is (default implem  
do not filter) :
     protected String toJavaFilterName(final Object obj, final String  
propertyName) {
         return propertyName;
     }

That method could be overrriden to filter or change property name.

If anyone found that usefull, feel free to ask the code.

I have to continue using it as it is on my projet and later on, I'll  
sit down to think about how this could be improved.

Hope this helps.

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Vincent Vandenschrick-2]

Hi Jean-Baptiste,
Another option might have been to provide your POJO classes with a
static method listing all the serializablePropertyNames, e.g. :
    public static Set<String> getSerializablePropertyNames();

Optimally, the method would return a static Set you construct in the
static block of the class.

Then simply invoke it using reflection in "protected Map filter(Object
obj, Map map)" overriden in a custom RemoteCallUtils. This way, you
don't have to change your beans accessors and keep them aligned with the
Java conventions (i.e. get/setProperty()).

Regards,
Vincent

Jean-Baptiste BRIAUD -- Novlog a écrit :

> Hi,
>
> As I said later on, here is a quick feedback of my use of JavaRPC.
> I used the HEAD of SVN contrib.
> I have some specific needs : reuse some POJO that I can modify. In  
> other words, the same POJO class are used not only by JavaRPC but also  
> by some other things.
> Basically, the only problem I was facing was the choice of what  
> property I wanted to exclude and what properties I wanted serialise  
> throw JavaRPC.
> I would love to do that with annotation or introspection using  
> transient Java keyword but this would involve too much JavaRPC  
> refactoring.
>
> Finally, I managed to stay in the current design : JavaBean  
> specification using Apache implementation to detect accessors.
> To reach my goal I simply added a new convention and a new method for  
> filtering properties.
> Rather than taking any accessors, I take only those who meet the  
> namming convention.
> The convention :
> Let's consider a property p.
> One "normal" accessor would be getP() and the other would be setP(P p).
> The convention for an accessor to be serialized throw JavaRPC is :
> set_ser_P() and get_ser_P(P p)
>
> So, the filter from Java to RPC is to keep only _ser_ accessors and  
> then to remove the _ser_ from Apache bean introspection Map so after  
> the operation all look like normal accessor.
> Then, for the other way around, from RPC to Java, all accessors are  
> rennamed by adding back _ser_ so the corresponding method on the POJO  
> accessors will be used to set back the values.
>
> This allow me to use accessors with the JavaBean design starting from  
> persistent POJO that are stored from fields annotations (not from  
> accessors).
>
> The only method I had to add to RemoteCallUtils API is (default implem  
> do not filter) :
>      protected String toJavaFilterName(final Object obj, final String  
> propertyName) {
>          return propertyName;
>      }
>
> That method could be overrriden to filter or change property name.
>
> If anyone found that usefull, feel free to ask the code.
>
> I have to continue using it as it is on my projet and later on, I'll  
> sit down to think about how this could be improved.
>
> Hope this helps.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>  

--
Vincent Vandenschrick
 Jspresso Framework
 http://www.jspresso.org


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with Crystal
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Vincent Vandenschrick-2]

Or simply annotate the getters of the properties you want to remain
transient with a custom @QxTransient. This annotation must have a
runtime retention policy so that you can test it using reflection, still
in your custom RemoteCallUtils.filter(Object , Map) method.

> Hi Jean-Baptiste,
> Another option might have been to provide your POJO classes with a
> static method listing all the serializablePropertyNames, e.g. :
>    public static Set<String> getSerializablePropertyNames();
>
> Optimally, the method would return a static Set you construct in the
> static block of the class.
>
> Then simply invoke it using reflection in "protected Map filter(Object
> obj, Map map)" overriden in a custom RemoteCallUtils. This way, you
> don't have to change your beans accessors and keep them aligned with
> the Java conventions (i.e. get/setProperty()).
>
> Regards,
> Vincent
>
> Jean-Baptiste BRIAUD -- Novlog a écrit :
>> Hi,
>>
>> As I said later on, here is a quick feedback of my use of JavaRPC.
>> I used the HEAD of SVN contrib.
>> I have some specific needs : reuse some POJO that I can modify. In  
>> other words, the same POJO class are used not only by JavaRPC but
>> also  by some other things.
>> Basically, the only problem I was facing was the choice of what  
>> property I wanted to exclude and what properties I wanted serialise  
>> throw JavaRPC.
>> I would love to do that with annotation or introspection using  
>> transient Java keyword but this would involve too much JavaRPC  
>> refactoring.
>>
>> Finally, I managed to stay in the current design : JavaBean  
>> specification using Apache implementation to detect accessors.
>> To reach my goal I simply added a new convention and a new method
>> for  filtering properties.
>> Rather than taking any accessors, I take only those who meet the  
>> namming convention.
>> The convention :
>> Let's consider a property p.
>> One "normal" accessor would be getP() and the other would be setP(P p).
>> The convention for an accessor to be serialized throw JavaRPC is :
>> set_ser_P() and get_ser_P(P p)
>>
>> So, the filter from Java to RPC is to keep only _ser_ accessors and  
>> then to remove the _ser_ from Apache bean introspection Map so after  
>> the operation all look like normal accessor.
>> Then, for the other way around, from RPC to Java, all accessors are  
>> rennamed by adding back _ser_ so the corresponding method on the
>> POJO  accessors will be used to set back the values.
>>
>> This allow me to use accessors with the JavaBean design starting
>> from  persistent POJO that are stored from fields annotations (not
>> from  accessors).
>>
>> The only method I had to add to RemoteCallUtils API is (default
>> implem  do not filter) :
>>      protected String toJavaFilterName(final Object obj, final
>> String  propertyName) {
>>          return propertyName;
>>      }
>>
>> That method could be overrriden to filter or change property name.
>>
>> If anyone found that usefull, feel free to ask the code.
>>
>> I have to continue using it as it is on my projet and later on, I'll  
>> sit down to think about how this could be improved.
>>
>> Hope this helps.
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> qooxdoo-devel mailing list
>> qooxdoo-devel@...
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>  
>
>

--
Vincent Vandenschrick
 Jspresso Framework
 http://www.jspresso.org


------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Jean-Baptiste BRIAUD -- Novlog]

I think there is no need to invent something new : transient old Java  
keyword is fully appropriate.
If a property is transient, then, no serialization.

The only problem is that transient keyword apply to field while  
JavaRPC is based on JavaBean's accessors and not fields.

It is the same foir persistence like JPA (a Java standard) : annotate  
the fields or annotate the accessors.
Both are possible, but the consensus and my prefered way is that  
annotating fields is better.

If a refactoring had to be thought on JavaRPC it could be to allow,  
like JPA, the choice of specifying the property to kept or to exclude  
via accessor or via fields annotation.
This would leave the choice.

In fact, my short term goal was to use JavaRPC changing code as less  
as possible but that discussion is important and interesting for next  
step : time for refactor.
So, feel free to add ideas ...

On Jul 27, 2009, at 21:05 , Vincent Vandenschrick wrote:

> Or simply annotate the getters of the properties you want to remain
> transient with a custom @QxTransient. This annotation must have a
> runtime retention policy so that you can test it using reflection,  
> still
> in your custom RemoteCallUtils.filter(Object , Map) method.
>> Hi Jean-Baptiste,
>> Another option might have been to provide your POJO classes with a
>> static method listing all the serializablePropertyNames, e.g. :
>>   public static Set<String> getSerializablePropertyNames();
>>
>> Optimally, the method would return a static Set you construct in the
>> static block of the class.
>>
>> Then simply invoke it using reflection in "protected Map  
>> filter(Object
>> obj, Map map)" overriden in a custom RemoteCallUtils. This way, you
>> don't have to change your beans accessors and keep them aligned with
>> the Java conventions (i.e. get/setProperty()).
>>
>> Regards,
>> Vincent
>>
>> Jean-Baptiste BRIAUD -- Novlog a écrit :
>>> Hi,
>>>
>>> As I said later on, here is a quick feedback of my use of JavaRPC.
>>> I used the HEAD of SVN contrib.
>>> I have some specific needs : reuse some POJO that I can modify. In
>>> other words, the same POJO class are used not only by JavaRPC but
>>> also  by some other things.
>>> Basically, the only problem I was facing was the choice of what
>>> property I wanted to exclude and what properties I wanted serialise
>>> throw JavaRPC.
>>> I would love to do that with annotation or introspection using
>>> transient Java keyword but this would involve too much JavaRPC
>>> refactoring.
>>>
>>> Finally, I managed to stay in the current design : JavaBean
>>> specification using Apache implementation to detect accessors.
>>> To reach my goal I simply added a new convention and a new method
>>> for  filtering properties.
>>> Rather than taking any accessors, I take only those who meet the
>>> namming convention.
>>> The convention :
>>> Let's consider a property p.
>>> One "normal" accessor would be getP() and the other would be  
>>> setP(P p).
>>> The convention for an accessor to be serialized throw JavaRPC is :
>>> set_ser_P() and get_ser_P(P p)
>>>
>>> So, the filter from Java to RPC is to keep only _ser_ accessors and
>>> then to remove the _ser_ from Apache bean introspection Map so after
>>> the operation all look like normal accessor.
>>> Then, for the other way around, from RPC to Java, all accessors are
>>> rennamed by adding back _ser_ so the corresponding method on the
>>> POJO  accessors will be used to set back the values.
>>>
>>> This allow me to use accessors with the JavaBean design starting
>>> from  persistent POJO that are stored from fields annotations (not
>>> from  accessors).
>>>
>>> The only method I had to add to RemoteCallUtils API is (default
>>> implem  do not filter) :
>>>     protected String toJavaFilterName(final Object obj, final
>>> String  propertyName) {
>>>         return propertyName;
>>>     }
>>>
>>> That method could be overrriden to filter or change property name.
>>>
>>> If anyone found that usefull, feel free to ask the code.
>>>
>>> I have to continue using it as it is on my projet and later on, I'll
>>> sit down to think about how this could be improved.
>>>
>>> Hope this helps.
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> qooxdoo-devel mailing list
>>> qooxdoo-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>>
>>
>>
>
>
> --
> Vincent Vandenschrick
> Jspresso Framework
> http://www.jspresso.org
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Vincent Vandenschrick-2]

I'm sorry Jean-Baptiste, I don't get your point. To my understanding,
the current JavaRpc implementation allows to plug any custom policy
using the RemoteCallUtils customization. You could even work with the
transient keyword if you like (using reflection), minus the fields
visibility problem (see below).

The problem with the Java transient keyword is that it is strongly tied
to the Java serialization (JVM <-> JVM).
Take for example a transient private field. It is correctly handled by
the JVM Object serialization but you will not get your hands on it
through reflection in a "standard" way. So unless you declare all your
fields public, I don't know if it's even possible to leverage the
transient keyword for achieving what you need from outside the bean
class, i.e. the JavaRpc library if your fields are private (and that's
good design to keep the object state private).
That's why I suggested the use of annotations on the getters (that are
public by design).

Moreover, there are times where Java beans don't have a "classic" state
with 1 property <-> 1 field. For instance they could declare a single
Map field to hold their property values and bean property accessors are
coded against this map.

BTW, Flex <-> Java serialization (using BlaseDS) works like Qooxdoo
(i.e. based on bean properties), except :
  -> built-in strong class typing when receiving beans on the Flex side
  -> only writable bean properties are passed over the wire.

Best,
Vincent

Jean-Baptiste BRIAUD -- Novlog a écrit :

> I think there is no need to invent something new : transient old Java  
> keyword is fully appropriate.
> If a property is transient, then, no serialization.
>
> The only problem is that transient keyword apply to field while  
> JavaRPC is based on JavaBean's accessors and not fields.
>
> It is the same foir persistence like JPA (a Java standard) : annotate  
> the fields or annotate the accessors.
> Both are possible, but the consensus and my prefered way is that  
> annotating fields is better.
>
> If a refactoring had to be thought on JavaRPC it could be to allow,  
> like JPA, the choice of specifying the property to kept or to exclude  
> via accessor or via fields annotation.
> This would leave the choice.
>
> In fact, my short term goal was to use JavaRPC changing code as less  
> as possible but that discussion is important and interesting for next  
> step : time for refactor.
> So, feel free to add ideas ...
>
> On Jul 27, 2009, at 21:05 , Vincent Vandenschrick wrote:
>
>  

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Jean-Baptiste BRIAUD -- Novlog]

On Jul 27, 2009, at 23:06 , Vincent Vandenschrick wrote:

> I'm sorry Jean-Baptiste, I don't get your point. To my understanding,
> the current JavaRpc implementation allows to plug any custom policy
> using the RemoteCallUtils customization.
No, you can only filter and rename property from Java to JSON direction.
I added the possibility to filter and rename property on the other  
direction : from JSON to Java.
> You could even work with the
> transient keyword if you like (using reflection), minus the fields
> visibility problem (see below).
>
No. This was my first error to think it could be done. Unfortunatly,  
transient apply to fields and JavaRPC rely on Apache beanutils lib and  
as you said later on, there can be more than one accessor for one  
field. So, it is possible to find a getX without an X field. So you  
can't use transient keyword in the current implementation.
> The problem with the Java transient keyword is that it is strongly  
> tied
> to the Java serialization (JVM <-> JVM).
I don't see that as a problem. JavaRPC is serializing, java instance  
to JSON string, so serialization apply perfectly to JavaRPC.
> Take for example a transient private field. It is correctly handled by
> the JVM Object serialization but you will not get your hands on it
> through reflection in a "standard" way.
This is not true as far as I understood what you want to say by  
"standard".
It is perfectly valid and standard to access private field via  
introspection. It works fine and most (maybe all) persistent framework  
like Hibernate or OpenJPA that no one can accuse to be non standard  
use it.
> So unless you declare all your
> fields public, I don't know if it's even possible to leverage the
> transient keyword for achieving what you need from outside the bean
It is possible, definitively.
> class, i.e. the JavaRpc library if your fields are private (and that's
> good design to keep the object state private).
> That's why I suggested the use of annotations on the getters (that are
> public by design).
Both should be possible. I never though to forbid use of annotation on  
getter, there is only a community consensus on annotating fields  
rather than accessors.
I do like choice, so both should be possible. As a comparison, it also  
work like that on Hibernate and OpenJPA just to take 2 examples.
You choose to annotate field or accessors and the generic mecanism of  
the framework take it into account.
So, finally, it is up to the developper-user of the framework to  
choose. I like that.
>
> Moreover, there are times where Java beans don't have a "classic"  
> state
> with 1 property <-> 1 field. For instance they could declare a single
> Map field to hold their property values and bean property accessors  
> are
> coded against this map.
This is not an issue. We are not here on a business layer but a  
technical layer.
If a class has only one accessor for 2 fields, this is an  
implementation choice of that developper's class.
In term of serialization, if fields are annotated, both will be  
serialized in JSON string.
On the other hand, if you annotate the accessor, only one property  
will be seen and serialize into JSON.
I don't see any problem in that behavior.
>
> BTW, Flex <-> Java serialization (using BlaseDS) works like Qooxdoo
> (i.e. based on bean properties), except :
>  -> built-in strong class typing when receiving beans on the Flex side
>  -> only writable bean properties are passed over the wire.
>

> Best,
> Vincent
>
> Jean-Baptiste BRIAUD -- Novlog a écrit :
>> I think there is no need to invent something new : transient old Java
>> keyword is fully appropriate.
>> If a property is transient, then, no serialization.
>>
>> The only problem is that transient keyword apply to field while
>> JavaRPC is based on JavaBean's accessors and not fields.
>>
>> It is the same foir persistence like JPA (a Java standard) : annotate
>> the fields or annotate the accessors.
>> Both are possible, but the consensus and my prefered way is that
>> annotating fields is better.
>>
>> If a refactoring had to be thought on JavaRPC it could be to allow,
>> like JPA, the choice of specifying the property to kept or to exclude
>> via accessor or via fields annotation.
>> This would leave the choice.
>>
>> In fact, my short term goal was to use JavaRPC changing code as less
>> as possible but that discussion is important and interesting for next
>> step : time for refactor.
>> So, feel free to add ideas ...
>>
>> On Jul 27, 2009, at 21:05 , Vincent Vandenschrick wrote:
>>
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Vincent Vandenschrick-2]

No, you can only filter and rename property from Java to JSON direction.

I added the possibility to filter and rename property on the other
direction : from JSON to Java.

Right, I didn't spot that.
 

No. This was my first error to think it could be done. Unfortunatly,
transient apply to fields and JavaRPC rely on Apache beanutils lib and
as you said later on, there can be more than one accessor for one
field. So, it is possible to find a getX without an X field. So you
can't use transient keyword in the current implementation.

Right.
 

I don't see that as a problem. JavaRPC is serializing, java instance
to JSON string, so serialization apply perfectly to JavaRPC.
This is not true as far as I understood what you want to say by
"standard".
It is perfectly valid and standard to access private field via
introspection. It works fine and most (maybe all) persistent framework
like Hibernate or OpenJPA that no one can accuse to be non standard
use it.

Right, I always thought that manipulating private fields and methods was prohibited globally by the JVM. But I've just found out that it was actually possible using Class.getDeclaredFields/Methods, then making them accessible before calling for their values. So you can actually leverage private fields/methods annotations/modifiers in JavaRPC.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel