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