Hi Ian, On Sat, 2015-05-09 at 08:41 +0100, Ian Boston wrote: > 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 ?
Right now I have the feeling that the Oak extension points are mostly there to help the Oak team with their own modularisation, not necessarily to ease contribution of alternative implementations. The Oak team has asked a couple of times for specific use cases for opening up APIs, rather than building up those APIs up front, see [1] for instance. So one suggestion would be to take this to the Oak team and ask for opening up more APIs. Another would be to embed to inline/embed the needed dependencies in your bundle ( or make it a fragment of an Oak bundle with the needed packages ). HTH, Robert [1]: http://oak-dev.markmail.org/thread/bphfhla7wzrhdwlj > > 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
