jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: enter() method for JCR implementation classes
Date Tue, 05 Mar 2013 15:39:52 GMT


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

Mime
View raw message