Hi, I see that the SecurityProvider reference in the oak-server bundle is marked as Greedy, indicating the intention to allow a replacement service from another bundle. I assume that was the intention ?
However, when I attempt to extract the Oak security subtree from oak-core ie org.apache.jackrabbit.oak.security.* to modify it there are bindings to org.apache.jackrabbit.oak.plugins.tree.impl.* which, obviously is not exported from oak-core. Looking at the code that depends on that, it looks like its impossible to implement a security provider without access to the impl classes, as by its nature it will need to access the internals of oak. My question: Since Oak Security Providers that do something real with security, can't be implemented outside of oak-core, should, in Sling we be promoting an OSGi approach ? This reminds me of the JR2 repository, where the only solution to adjusting the security model to cover use cases not considered in JR2 was to do some fairly nasty, and unmaintainable hacks. If there is an alternative way, please say. I would rather not expose impl details of Oak core, or ask for the classes to be moved. Best Regards Ian
