question related to MarshalledInputStream

[Mark Brouwer <ma...@cheiron.org>]

I'm extending MarshallInputStream at the moment for experimenting with
some class loader swapping while unmarshalling objects.

The idea is that I override resolveClass(ObjectStream) and use for some
special cases a different class loader than the one passed in at
construction time (has something to do with unmarshalling service
discovery events).

While extending MarshallInputStream I noticed that I have to supply some
properties to the superclass constructor that are final but not
accessible from a subclass while I do need them. The solution is simple,
I just duplicate them in my subclass but I wonder why defaultLoader,
verifyCodebaseIntegrity, verifierLoader and context were not made
protected here as I need to supply them to the super class anyway.
-- 
Mark

Re: question related to MarshalledInputStream

[Mark Brouwer <ma...@cheiron.org>]

Bob Scheifler wrote:
> Mark Brouwer wrote:
>> I wonder why defaultLoader,
>> verifyCodebaseIntegrity, verifierLoader and context were not made
>> protected here
> 
> The context is available via a public method.  For the others, I'd
> say due to thinking akin to Josh Bloch's advice in Effective Java,
> only minimal subclassing hooks were put in to start, pending
> clear need for more.

Josh Bloch, hmmmm I think I vaguely heard of him ... isn't he also the
guy that favors interfaces over (abstract) classes and says your equals
should be stable so therefore not rely on URL.equals as a key in a map
or something like that?

I'll file an issue against MarshalledInstance as it seems the
reason for subclassing works for what I try to accomplish.

BTW I must say that extending BasicInvocationDispatcher and
BasicILFactory for various of my needs has been a pleasure, the Jini ERI
stack is really well done.
-- 
Mark

Re: question related to MarshalledInputStream

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> I wonder why defaultLoader,
> verifyCodebaseIntegrity, verifierLoader and context were not made
> protected here

The context is available via a public method.  For the others, I'd
say due to thinking akin to Josh Bloch's advice in Effective Java,
only minimal subclassing hooks were put in to start, pending
clear need for more.

- Bob