Re: using different classes on the client and server side

On Apr 8, 2005, at 1:05 PM, John Didion wrote:

> Instead of the normal model of using the same service interface and
> objects on both the client and server, we're generating a client stub
> [1]. Will this just work, or do we have to write a custom Serializer
> and
> Deserializer?

You might need to just try it, but I think it should work.

The issue is which class Hessian should instantiate for the returned
bean.

If you look at HessianInput.readObject(Class), Hessian will look at the
'type' attribute of the input (which will be "server.Bar"), and compare
it to the expected class "client.BarClientObject".

Since Bar is not assignable to BarClientObject (and might not even be
on the client), Hessian will instantiate BarClientObject instead and
populate it with the "baz" field.

That only works when readObject knows the expected class. So the proxy
calls readObject() instead of readObject(Class), you might get some
nonsense in return (probably a HashMap.)

-- Scott

>
> Thanks in advance.
>
> [1] an example of what we're doing:
>
> Server
> ----------
> package server;
>
> public interface FooService {
> Bar getBar();
> }
>
> package server;
>
> public class FooServiceImpl {
> Bar getBar() {...}
> }
>
> package server;
>
> public class Bar {
> private String baz;
> public String getBaz() {...}
> public void setBaz(String s) {...}
> }
>
> Client
> ----------
> package client;
>
> interface FooClient {
> BarClientObject getBar();
> }
>
> package client;
>
> class BarClientObject {
> private String baz;
> public String getBaz() {...}
> public void setBaz(String s) {...}
> }
>
> Usage
> ----------
>
> BarClientObject obj =
> ((FooClient) new HessianProxyFactory().
> create(FooClient.class, url)).
> getBar();
>
Received on Fri 08 Apr 2005 14:15:26 -0700