Hi Bertrand, Just a word of caution. The JCR API has some quite rich and complex semantics. I can understand how the wrapper can be useful for testing an existing system based on JCR, but I would be more skeptical if I saw this code used in production overriding or enriching the behaviour of the API. Moreover, the JCR API encourages a very fine-grained interaction with the underlying storage system and, because of this reason, it's often on the critical path. Pay special attention not to add too much overhead to whatever you wrap, otherwise you might introduce subtle bugs in your system which will be difficult to understand.
When it comes to testing systems based on JCR, I found in the past that some alternatives are better than mocking or wrapping the JCR API. In particular, - Use a real JCR implementation to create test data for your application. This is the most widespread testing strategy, and I guess that you are doing this in Sling extensively. - Use new and better abstractions to hide the JCR API. I find this a better way to decouple your code from a specific persistence implementation. Additionally, it makes your system more testable and portable. It's probably a more complicated strategy, but you will reap bigger benefits in the long run. On Fri, 25 Jan 2019 at 17:12, Bertrand Delacretaz <[email protected]> wrote: > Hi, > > FYI we have created together with Karl Pauls a library of wrappers for > the JCR API, that in theory allows one to intercept JCR calls for > various purposes. > > I'm saying "in theory" as it's an early version that hasn't been > tested much so far, but worked in simple use cases like pre-loading > and simulating JCR content. > > The code is at > https://github.com/apache/sling-whiteboard/tree/master/jcr-wrappers > in the Sling whiteboard, if there's interest we might move it to > Jackrabbit at some point (it has no Sling dependencies except a minor > test library) but as we're both Sling committers it's easier for us to > play with it there for now. > > -Bertrand >
