jabsorb Java client and Unmarshall exceptions

[Dave Combs]

I'm trying to use the Jabsorb Java client (Client/Session objects)
support to build an Eclipse RCP client, but am having problems with
being able to unmarshall return values after successfully contacting
the server.

As a test, I've declared an API (IFooApi) that has a method
public String getMessage(String key)

When I build things with this, everything works fine--I can send the
key over and get a return value back.
If I change the signature to
public IClientResult getMessage(String key)

(an interface both server and client know about), and have the server
return an instance of ClientResultImpl
(that implements IClientResult, which is declared in the same
package),
everybody compiles fine, the server code executes correctly, but the
JSONSerializer unmarshalling code
throws an UnmarshallException because it can't find the class
ClientResultImpl.

Is there a specific way that I can tell the JSONSerializer that the
concrete ClientResultImpl class exists?
How does it determine how to unmarshall the class (since it already
has the class hint in the return value?

Thanks!
Dave Combs

[Sasha Ovsankin]

Dave --

You can try to feed JSONSerializer.registerSerializer() with a class
that will know how to map interface to implementation.

I am still curious about your use case -- it looks like your Client
Result is a classic transfer object and I am not sure why would you use
the Interface/implementation pair here instead of just POJO.

However if you want to do keep the implementation object on the server
side and call methods of this object remotely you should look into
JSONSerializer.registerCallableReferences().

Regards,
-- Sasha

[Dave Combs]

Thanks, Sasha. I'll look into registerSerializer() this morning.

Regarding ClientResult, you're right that this particular one looks
like
a classic transfer object. This was just the first test for what will
likely
become a set of objects, some of which already exist with various
methods and other structure on the server that I didn't want to expose
on the client. Since I needed two implementations of the object with
somewhat different functionality, I was going with the interface/
implementation
style. I could, of course, do it just using a POJO object with less
behavior and write other wrapper objects on both sides to provide the
behavior.

Here's a trivial example based on my original test (suggestions for
object
style are appreciated!)
The real 'ClientResult' object will pass back a status code and
message
along with a value. I want methods to be able to set the status code
and
message on the server, but only to read it on the client. I can write
a POJO
that has getters and setters, and use the setters on the server and
getters
on the client, but that doesn't prevent the client from using setters
too.
(Obviously this isn't a real big problem with status and message, but
it
illustrates what I'm hoping to avoid.)

Thanks!
Dave