river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: RiverClassLoaderSPI
Date Fri, 09 Nov 2012 12:48:28 GMT
Simon IJskes - QCG wrote:
> On 09-11-12 00:31, Peter Firmstone wrote:
>> Ok, because it's small I think we can consider it, can you provide the
>> hooks to load different providers?  The non default providers themselves
>> can be a subproject.  We need to carefully consider security since we're
>> making it possible for downloaded code to resolve classes.
>> My SecurityManager and policy providers were developed in skunk, then
>> merged.  URI changes were made in trunk, although this was a big change
>> semantically, the code footprint is small.  For large changes to
>> foundation code we need skunk, not everything can be bolted on or
>> plugged in.
> I have difficulty understanding what you are talking about. Could you 
> try again?
> Gr. Simon
Ok, I reimplemented net.jini.security.policy.DynamicPolicyProvider and 
created org.apache.river.api.security.ConcurrentPolicyFile and a heap of 
package private support classes, including a policy parser based on 
Harmony code.  These policy providers have no cache and utilise 
immutability for concurrency.  Then there's 
org.apache.river.api.security.CombinerSecurityManager, which caches 
security check results for concurrent code to support very fast repeated 
security checks.  That was all performed in a skunk branch, then merged 
after passing qa tests.
It has since been slimmed down somewhat as well and undergone some minor 

The changes I made to support URI in place of URL, where it made sense 
to, was committed directly to the stable trunk.  But the effort involved 
is much less than that required for the policy providers and security 
manager, which would have been practical to develop in trunk.

I was basically saying in a very roundabout way that skunk has its 
place, for more complex changes.



View raw message