river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bharath Kumar <bharathkuma...@gmail.com>
Subject Re: Have we been doing codebase annotations wrong?
Date Wed, 31 Jan 2018 16:20:38 GMT

I am excited and I would like to see its implementation.
If possible, please share it.

Current River implementation uses ClassAnnotation to annotate codebase. which
is implemented by PreferredClassLoader.
I find it difficult to use it with OSGi environment.
So I am using  ThreadLocal variable to annotate codebase annotation in OSGi
Smart proxies will be annotated using this ThreadLocalVariable which has
codebase annotation,
But I don't know whether it will work for all cases.


On 31 January 2018 at 12:56, Peter Firmstone <peter.firmstone@zeus.net.au>

> Have we been doing codebase annotations wrong?
> Could RMIClassLoader have been better conceived?
> Could a simpler alternative be utilised instead?
> For example, classes are resolved differently during deserialization than
> how classes are resolved at runtime. At runtime a ClassLoader delegates to
> its parent ClassLoader, or in the case of modular systems, ClassLoader’s of
> imported modules. RMIClassLoader, doesn’t look to resolve classes through
> ClassLoader hierarchies, but instead tries to locate each ClassLoader
> directly based on an annotation.
> The problem with this approach is not all ClassLoader’s provide codebase
> annotations, and class resolution may be different at distinct nodes in the
> network.
> Currently codebase annotations may change when marshalling between nodes,
> depending on where each class is resolved.
> Refer to: http://sorcersoft.org/resources/jini/smli_tr-2006-149.pdf
> A much simpler approach.
> We can define the ClassLoader at each endpoint.
> In JERI, a ServerEndpoint can be assigned a default ClassLoader, by
> passing it as a parameter to its InvocationLayerFactory. The client
> Endpoint’s default ClassLoader is the ClassLoader of its dynamic proxy
> instance (the ClassLoader where the java.lang.reflect.Proxy dynamically
> generated instance is loaded).
> So if a service has a smart proxy, it’s codebase should be present in a
> ClassLoader at both the ServerEndpoint and the client Endpoint, so the
> default ClassLoader’s at both Endpoint’s contain that codebase.
> The default ClassLoader at each Endpoint now has responsibility for
> resolution of classes, no longer is RMIClassLoader required. In fact
> codebase annotations no longer need to be annotated with every class in the
> stream either.
> But what about client parameter objects, or exported remote handback
> objects passed as parameters, I hear you ask?
> Simple, we use a marker interface, so these objects can identify
> themselves to the stream, a bootstrap proxy can be provided by the stream,
> that uses only local classes, present at both endpoints, the original
> object can be stored into a MarshalledInstance and serialized with the
> bootstrap proxy to the remote Endpoint, that allows the originator to be
> authenticated, it’s codebase provisioned into a ClassLoader which becomes
> the default loader of the MarshalledInstance to deserialize the object in
> question. The identity key of the ClassLoader will be a combination of the
> bootstrap proxy’s InvocationHandler identity and it’s codebase annotation,
> so it can be cached. If a remote object which is contained within the
> MarshalledInstance, its JERI Endpoint will use the default ClassLoader
> passed to the MarshalledInstance as its default loader.
> Note: If we’re in a traditional java hierarchical ClassLoader system (not
> modular), we’d want the current stream’s default loader to be the parent
> loader of the resolved or provisioned ClassLoader passed to the
> MarshalledInstance.
> So now you don’t get codebase annotation loss, ServerEndpoint and client
> Endpoint’s have ClassLoader’s with compatible class resolution. The
> codebase annotation becomes a configuration concern of the service.
> In addition, MethodConstraints can also be applied to exported objects
> nested within other services. It can be passed using the stream context.
> This ensures that minimum principal authentication, integrity and
> confidentiality apply to all nested objects.
> The good news is that most of the mechanisms are already present and
> backward compatibility can be preserved allowing eventual migration.
> Remember that a smart proxy can have no real server back end communication
> at all (except for providing the codebase), it’s just an object that gets
> serialized around different nodes, in this case the bootstrap proxy is
> still used to provide the codebase annotation and as trust verification.
> How does trust work in this system?
> Provided you still trust the bootstrap proxy’s service, after method
> constraints that ensure confidentiality and minimum principal
> authentication have been applied , it provides the codebase annotation, and
> if integrity constraint is true, then the codebase scheme is checked for
> integrity, or if it’s signed, the jar is validated by a provider. (The
> signers can be anonymous and advised by the bootstrap proxy). You now trust
> that the code will validate input during deserialization, and if the
> de-serialized object implements RemoteMethodControl apply MethodConstraints
> to it as well. The object bytes in serial form may have originated from a
> third party (also with MethodConstraints applied, but possibly not trusted
> by the original node), in any case it’s important for the input to be
> validated during deserialization.
> Note this system would also utilise a Service Provider Interface to
> communicate with the bootstrap proxy and preferred classes can still be
> supported, simply by using a PreferredClassLoader when loading the codebase.
> This system also allows support for modular environments like OSGi to be
> relatively simple when compared to RMIClassLoaderSpi. Additonally it allows
> an OSGi node to interact with traditional nodes / services, provided jar
> files have bundle manifests and the configured codebase annotation string
> contains all required jar files, including dependencies (the OSGi provider
> can ignore the dependencies, provided the first jar is the proxy bundle).
> I've currently got a prototype I'm working on if anyone's interested.
> Regards,
> Peter.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message