Actually, the Sling POST Servlet bundle has a dependency on the JCR API, as does SlingFileUploadHandler.
In that case #2 seems the best way forward. Use oak:Resource if available, otherwise fall back to nt:resource. Regards Julian On Mon, Oct 3, 2016 at 10:49 AM, Chetan Mehrotra <[email protected]> wrote: > On Mon, Oct 3, 2016 at 2:01 PM, Oliver Lietz <[email protected]> wrote: >> I'm aware of that thread and therefore suggest to drive the spec towards >> version 3. Providing tools for upgrading from 2 to 3 would allow to break >> backwards compatibility and evolve. > > I believe this is orthogonal to current issue that we are discussing. > Something which require wider effort! In this thread I would prefer to > focus on the issue at hand and determine the approach to take. > >> When using special Oak nodetypes (and moving further away from JCR) we should > stop claiming to be a web framework using JCR but Oak. > > That may be one option as authentication layer depends on how Oak > authentication works. But if we want to stick to JCR we can define our > own nodetype and use that and not rely on Oak specific nodetype > (Option #3) > > Chetan Mehrotra
