A little more background on AtomicILFactory

[Peter <ji...@zeus.net.au>]

JERI is of course extensible, there are a number of layers:

   1. Invocation Layer.
   2. Object identification layer
   3. Transport layer.

All proxy's that use JERI contain a java.lang.reflect.Proxy instance 
that uses an InvocationHandler from an invocation layer factory.

Currently we have BasicILFactory, this uses standard java serialization 
and Marshal streams from the net.jini.io package, which annotate streams 
with codebase annotations.

The invocation layer provided by BasicILFactory allows you to download 
any class from anywhere.   Serialization was considered secure, at the 
time when it was written.  To be fair, serialization should have been 
maintained secure.   In this model, after you deserialized a proxy into 
its downloaded code, then you ask the remote end to check it, and then 
you apply constraints.    The problem today is serialization is not 
secure, and we can use a secure transport layer, however a proxy can 
download another proxy that doesn't use a secure transport layer and the 
constraints won't be applied to it.   For example, Reggie provides a 
lookup service, you can apply contraints against it, but it can still 
download proxy's from other services and the constraints aren't applied 
to those.

Enter AtomicILFactory, it utilises codebase annotations still, but in a 
limited form.   Instead of using codebase annotations for every class, 
each endpoint is assigned a default ClassLoader that determines class 
visibility and resolution.   The service's server endpoint is assigned a 
ClassLoader by AtomicILFactory, but how is its proxy ClassLoader 
determined you ask?   Ok, so we need to go back one step, proxy's are 
marshalled independently of the stream, this means, unlike 
BasicILFactory, Reggie cannot download proxy's from other services, 
because their proxy classes won't be available via the default 
ClassLoader.  Instead, proxy's are marshalled by a ProxySerializer, that 
contains a MarshalledInstance and a CodebaseAccessor bootstrap proxy, 
which only utilises local classes.   There's a new provider 
net.jini.loader.ProxyCodebaseSpi, which the ProxySerializer passes the 
MarshalledInstance and CodebaseAccess to as arguments.    The bootstrap 
proxy is used for authentication and codebase provisioning, the 
provisioned ClassLoader is then used by the MarshalledInstance to 
deserialize the proxy.   So this is how the ClassLoader is established 
for the proxy.

Now I was applying constraints to the proxy before it returns, but this 
breaks a number of InvocationHandlers, that are expecting a proxy 
without constraints, so for now, constraints are only applied to the 
bootstrap proxy.

There are two ProxyCodebaseSpi implementations, one for preferred 
classes, the other for OSGi.

Note the parent ClassLoader is the loader of the stream that 
deserialized the proxy in it's marshalled form, at least for preferred 
class loading, but not for OSGi.  The reason is, a service proxy may 
already contain proxy's for other services, which it utilises privately, 
so it needs to be able to control the visibility of classes using 
preferred class loading, the interfaces shared by the service proxy and 
other proxy's it contains

This gives the client total control over who can download classes and 
enforce constraints before deserialization occurs.

I haven't made this code publicly available yet.

Regards,

Peter.