Java.rmi.NoSuchObjectException with custom InputStream/OutputStream

Question

I'm experiencing a strange problem here...and have spent the night digging for an answer,
but I don't see any...
I am using a custom client/server socket factory, which works great until I return my
custom In/Out streams from the custom Socket. I can return a BufferedInputStream
wrapping the socket's InputStream, but if I write a subclass BufferedInputStream
(and override no methods) I get the NoSuchObjectException...
any ideas?
public class BInputStream extends java.io.BufferedInputStream {
  private InputStream in = null;
  public BInputStream(InputStream in) {
    super(in);
    this.in = in;
}

Answer 1

What I am trying to do (and have done with the minor limitation that I cannot use
custom streams to compress the RMI traffic...) is create a totally transparent proxy
for RMI services.
The Proxy object is for any Remote object. A Proxy is returned to the client
containing a Remote Invoker that is called by the Proxy's InvocationHandler.
Since this is for a known environment, there is no need for dynamic class loading,
so the JVMs must all have the classes to talk to one another...
  A <---> B <---> CI want to, now, compress the A <--> B link, because it is over a saturated link, and
a cursory look at the actual data tells me I can compress 300k, which is a standard
transaction size (after pruning classpath entries from the clients), to around 40k
(conservative estimate). Obviously, this is a huge improvement in any environment,
but an especially appealing one considering the fact that this link slows, literally, to
a crawl at times. I already have the inflate/deflate streams worked out as far as I can
test them, so all I need to do is get past this current stumbling block and test the
compression bits in an environment more representative of the deployment env.
Anyway, that's the highest level goal :-)
So, a question...to confirm what I believe I found earlier that led me into this bowl
of noodles (really, it's not that bad, except that I can't debug the code once
it wanders off into RMI land, which may indicate a problem in my design :-P)...
[after some more time poking around to make sure I'm not asking a stupid
question]
It seems my spaghetti (the exporting of the Invoker inside of the InvocationHandler)
is necessary for the transparency I desire. As it turns out, I know enough now to
find useful information from google on this subject :-) That's some progress!
It seems springframework has something exactly like the server half of my
system, so I'm gonna take a look at that as I wind this day down.
cheers.
b