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
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
