Hi, I have created patches for Jackrabbit and Oak including test coverage. They are attached to: https://issues.apache.org/jira/browse/JCR-3870 https://issues.apache.org/jira/browse/OAK-3166
Could you please review and apply them? - Joel On 07 Apr 2015, at 15:13, Joel Richard <[email protected]<mailto:[email protected]>> wrote: Thank you for your suggestions. I have opened the following two issues to fix this problem: https://issues.apache.org/jira/browse/OAK-2724 https://issues.apache.org/jira/browse/SLING-4585 - Joel On 07/04/15 07:58, "Angela Schreiber" <[email protected]> wrote: Hi Michael I would opt for the Jackrabbit API variant. Changing the semantics of the JCR API call is asking for severe troubles and I don't see any additional effort for another version of the spec (in particular since JSR 333 was never implemented in Jackrabbit or Oak). Extending the JackrabbitSession interface however, should be quite painless and equally serving the purpose. Kind regards Angela On 07/04/15 09:54, "Michael Dürig" <[email protected]> wrote: On 7.4.15 9:00 , Joel Richard wrote: Hi, In JcrResourceProvider.createResource (Sling) it uses fist Session.itemExists to check whether an item exists and then Session.getItem to retreive it. Even though the item data is cached for the second call, this adds 8% overhead to the page rendering. 14% of the whole page rendering time is spent in itemExists. Sling could just only use getItem and catch the exception if the item does not exist. Unfortunately, this will not perform well if the resource resolver is often used to read items which do not exist because exceptions are slow. This also bothers me for a long time now. I think it is an unfortunate design decision of JCR to either force clients to use Exceptions for flow control or to have to go through 2 API calls. Technically, the simplest solution would be to export the method getItemOrNull. This method could be Oak-specfic and only be used by Sling when running on Oak. t would at least be simple to extend the Jackrabbit API in such ways. Another approach would be to introduce sentinels representing non existing items. Clients could then do something along the lines of Node n = session.getNode("/foo/bar"); if (n == JackrabbitNode.NULL) { // no node at /foo/bar } else { // default case } We are using this pattern quite a bit within Oak reducing a lot of boilerplate. However retrofitting it to JCR comes with compatibility issues, which we'd need to address. Michael
