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
refactorings.
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.
Cheers,
Peter.
