On 5.3.13 9:56, Jukka Zitting wrote:
Just some anecdotal evidence: a single call to Node.addNode() results in a
>call to Node.getPrimaryNodeType() which in turn ends up calling
>Property.getValue() and which eventually results in a call to
>Property.isMultiple(). So there will be quite a bit of stuff to untangle.
>Not sure how to go about this in order to catch them all.
Yeah, I find this pattern somewhat troublesome and much more prevalent
than I'd expected. It would be good to avoid crossing the JCR API
boundary multiple times during the execution of a single operation. To
do this, I'd suggest we adjust the Impl/Delegate boundary as follows:
Responsibilities of JCR Impl classes:
- name/path mapping for both method arguments and return values
-> NamePathMapper should be in SessionImpl instead of SessionDelegate
- tracking and instantiation of other JCR Impl objects
-> Delegate classes should refer to neither the JCR API nor the Impl classes
-> Values should be returned as PropertyState instances that are
mapped to JCR Values by an Impl class
Delegate classes
- access to the Oak API
- the checkStatus() and perform() logic
-> Something like:
- all the "business logic" associated with complex operations
-> the complex SessionObject classes from Impl classes should be
pushed down to Delegates
-> dlg.perform(dlg.getSomeOperation(oakName, ...))
To make it easier to enforce such a stricter design boundary with
tools like JDepend, I'd move the Delegate classes to a separate
package structure under o.a.j.oak.jcr.delegate.
Ack. I created https://issues.apache.org/jira/browse/OAK-672 to track this.
Michael
