Re: Bootstrap stubs with fixed UUIDs

Peter Jones <[email protected]> Wed, 25 Mar 2009 13:59:22 -0400
Newsgroups gmane.comp.java.sun.jini
Message-ID <20090325175921.GA7579@east>
On Wed, Mar 18, 2009 at 06:43:24PM -0600, Esmond Pitt wrote:
> Should ProxyTrust also be in the list of interfaces?

Partly, it depends on whether the target remote object supports
supplying a proxy trust verifier to clients, either by implementing
ProxyTrust itself or by implementing ServerProxyTrust.  If it
implements ProxyTrust, then inclusion of that interface would follow
from it being one of the object's remote interfaces.  If it implements
ServerProxyTrust and was exported with a BasicInvocationDispatcher
(like through ProxyTrustILFactory), then it would also be appropriate,
because BasicInvocationDispatcher forwards ProxyTrust.getProxyVerifier
to ServerProxyTrust.getProxyVerifier on the remote object.  If it was
exported with ProxyTrustExporter-- well, you probably wouldn't be in
that situation with a remote object that you expected clients to
synthesize their own such bootstrap stubs to.[*]

On the other hand, if this bootstrap stub is simply a dynamic proxy
defined by a trusted class loader and only contains instances of local
JERI classes-- it's not a "smart proxy" with downloaded code-- and it
is not intended to be passed to another JVM, then the local JERI trust
verifiers should be sufficient for a trust verification operation, and
ProxyTrustVerifier shouldn't be needed, so whether the stub implements
ProxyTrust is likely moot.

-- Peter

[*] But for completeness, the top-level invocation handler in that
case would be a ProxyTrustInvocationHandler, and it would be the
contained "bootstrap proxy"-- in the other sense of bootstrapping
proxy trust verification-- that would need to implement ProxyTrust.

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]