Re: using different classes on the client and server side

On 4/8/05, Scott Ferguson <ferg@xxx.com> wrote:
> On Apr 8, 2005, at 2:27 PM, John Didion wrote:
[snip]
> Yes, that's what it should be doing.
>
> As long as your client specifies exactly which classes it expects, e.g.
> by using Foo[] instead of ArrayList<Foo> (until generics are
> supported), then it doesn't matter what implementation type the other
> end is sending.
>
> -- Scott
 
It works, but only because the type of Bar.baz is a String. If it
wasn't a primitive type (or a List), the server would choke as it
wouldn't be able to isntantate the object. The server will only
override the types of the interface methods' arguments.

The way I have got around this issue was to send memento classes, with
readResolve() methods that instantiate the correct type. (The nice
thing of these approach is that client and server can have different
versions of a type and its memento, as long as the fields in the
mementos match.)

However, and this is something I have been meaning to post about, I
wanted memento objects to be transparent to users and implementers of
an interface. In order to achieve that, I had to modify the Burlap
sources, as Burlap blindly ignores received types if they do not match
those of the method definition.

Here is an example that might make things easier to understand.

Assume that both client and server have the following classes (the
server would also have an implementation of the service):

interface TacoServce
{
    Taco prepareSpicy( Salsa suicide );
}

class Salsa
{
    // all soft of spicy goodness here...

    public Object writeReplace()
    {
        return dehydrate();
    }

    PowderedSalsa dehydrate()
    {
        return new PowederedSalsa( .. );
    }
}

class PowderedSalsa // note that it does *not* extend Salsa
{
    String powder;

    public Salsa readResolve()
    {
        return new Salsa( justAddWater( powder ) );
    }
}

Now if the client calls TacoService.prepareSpicy() with a Salsa
instance, Burlap will happily turn the Salsa into PowderedSala. In the
server side however, Burlap, seeing that the sent type is different
than the expected type, will choke if it doesn't have access to a
Salsa constructor, or even worse, it will try to instantiate a Salsa
using the fields of a PowderedSalsa.

Scott, would you consider a patch so that this behaviour can be
overridem in a standard way? I don't have the piece of code right now,
otherwise I'd post more details, but I'll get around to it.. Please
note that all this discussion is about Burlap, but I expect Hessian
behaves the same way.

I hope the example makes sense, I'm working from memory.. and I guess
I'm hungry! :-)

Best Regards,

Victor Rodriguez.
Received on Wed 13 Apr 2005 22:45:41 -0700