Yes, I've been thinking about it.
My current thoughts; ServiceUI can be accessed through
net.jini.lookup.ServiceAttributesAccessor, so you can unmarshall
ServiceUI objects, without unmarshalling the service itself. However I
haven't given much consideration to locating codebases for ServiceU
Yes that's correct.
Sun chose to use the ClassLoader to represent the service's pincipal,
dynamically granting permission after proxy verification.
So that's what we have available on the call stack to use when
performing authorisation permission checks:
1. Client's Principal. (Principal
Hi Peter,
In reading your missive I'm not sure I understand when you say "Maven will
present a new alternative of maximum sharing, where different service
principals will share the same identity.", or "Maven class resolution".
Are you referring to an approach where a service may declare it's code
Do you have anything planned around ServiceUI? I really use ServiceUI as a
discovery mechanism to find services which export a UI that a user can interact
with. What can happen at registration time, besides Entry specification to
help with codebase where ServiceUI bits are at? Are you just re
cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html
Some updates on thoughts about OSGi:
1. In JGDMS, SafeServiceRegistrar (extends ServiceRegistrar),
ServiceDiscoveryManager and ProxyPreparer allow provisioning of
OSGi bundles for Jini services.
2. SafeServiceRegistrar lookup results contain only instances of
java.lang.reflect.
