[
https://issues.apache.org/jira/browse/RIVER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michal Kleczek updated RIVER-436:
---------------------------------
Attachment: codebase.patch
This is a first patch created against qa_refactor branch.
It is not tested - just attached here for review.
The architecture looks sound.
Goals achieved (probably :) ):
1. Establishing trust of downloaded code prior to execution
2. Extensibility of class loading mechanism
3. Backwards compatibility (to be refined but the idea looks ok)
4. Fixed issues with current class loading - because codebases are now objects
they can encode much more information. Default implementation (RmiCodeBase) is
hierarchical. A NonActivatableCodeBaseServiceDescriptor is provided to create a
proper ClassLoader hierarchy when starting services. This hierarchy is going to
be maintained and recreated on remote clients. Additionally the actual
resources are accessed through RMIResource which identity is not tied to URL
but name and secure hash. It caries with itself a set of URLs where the
resource can be downloaded from and provides a simple fallback mechanism when
accessing them. The set of URLs is merged on each node so when RMIResource is
sent further it is going to have more URLs. So code server information
"spreads" throught the network.
Since RMIResource identity is not tied to URL it is enough for two services to
have the same hierarchy of ClassLoaders - each of them loaded from it's
RMIResource - to share classes by recreating the tree of ClassLoaders on remote
ends.
> Codebase annotations should be objects implementing a known interface instead
> of Strings
> ----------------------------------------------------------------------------------------
>
> Key: RIVER-436
> URL: https://issues.apache.org/jira/browse/RIVER-436
> Project: River
> Issue Type: New Feature
> Components: net_jini_core, net_jini_io, net_jini_security
> Reporter: Michal Kleczek
> Priority: Minor
> Attachments: codebase.patch
>
>
> Right now codebase annotations are Strings containing a space separated list
> of URLs . This has several drawbacks:
> 1. Code downloading is not dynamically extensible. All the parties in the
> network have to apriori agree on a set of URL handlers. Introduction of a new
> provisioning mechanism - for example based on Maven - requires at least
> reconfiguration of all participants
> 2. There is no way of verifying downloaded code before it is actually
> executed. Right now a TrustVerifier is obtained and used only after a service
> proxy was deserialized which enables untrusted code to execute during
> deserialization (see also RIVER-362).
> The idea is to make code downloading extensible. Codebase annotations should
> be objects implementing a well known interface encapsulating the way how code
> is downloaded.
> Prior to execution codebase annotations would be verified for trust.
> That way:
> 1. Clients are decoupled from the mechanism used to download service proxy
> code
> 2. No code is executed before verifying the codebase for trust.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
