Hi, I agree with the approach taken by the Oak team, no point in creating api bloat if there is no demand for it.
However, it seems that trying to do what I am doing outside Oak core really is too hard, so I have opted to patch Oak core. Fortunately Oak core appears well structured and the patch is relatively small. I am however finding the Sling Authentication stack hard to work with a user name and password go through many transformations before they eventually arrive at the ContentRespositoryImpl.login method. There are many pathways which a login operation could take scattered through several bundles, each transformation obfuscating the operation. Obviously only 1 path is used, but finding it is non trivial. Thats just an observation, not a request for change. Best Regards Ian On 18 May 2015 at 10:03, Robert Munteanu <[email protected]> wrote: > 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 > >
