Re: When moving a Tree, can it die?
Hi, On 4.10.12 16:34, Jukka Zitting wrote: Tree r = root.getTree(/); Tree x = r.getChild(x); Tree y = r.getChild(y); root.move(/x, /y/x); assertEquals(y, x.getParent().getName()); To avoid this problem, I'm wondering if we could allow a Tree instance that was acquired before the move to become invalid or disconnected? Any changes to a Tree instance in such a sate would just be discarded and the return values of methods like getParent() or getLocation() would be undefined (typically returning the values they had before the move). That behaviour is already there in the case of Root.refresh() and Root.commit() being called. See the respective Javadoc. In this case getPath() on an invalid Tree instance returns the previous value. This is currently used to re-resolve JCR Items after refresh/commit. However in the case of a move operation I think this would cause the above test case to fail, since x.getParent() would then still point to the root. Maybe we could just throw an InvalidItemStateException for such cases? This would simplify things considerably, let us get rid of the children weak refs, and might also open up a way to reduce the number of re-resolves taking place. As Marcel pointed out yesterday, the latter also shows up as bottleneck in read performance. Michael
buildbot success in ASF Buildbot on oak-trunk
The Buildbot has detected a restored build on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/691 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1394410 Blamelist: alexparvulescu Build succeeded! sincerely, -The Buildbot
Re: buildbot failure in ASF Buildbot on oak-trunk
the changes are back in, this time all the tests pass :) sorry about the noise, thanks Michael for keeping an eye on things. best, alex On Thu, Oct 4, 2012 at 5:51 PM, Michael Dürig mdue...@apache.org wrote: There seems to be more to it. So I reverted the changes from revisions 1394092, 1394101, 1394112 because the cause QueryTest and NodeDefTest to fail. QueryTest: Probably we only need to adjust the test expectations. But I'm not sure here. NodeDefTest: This might also be a problem in another area which is only discovered by these changes. If so, I suggest to ignore these tests and create an issue. Michael On 4.10.12 16:18, Michael Dürig wrote: This is QueryTest.sql2_measure failing. It seems the new node type introduced in revision 1394101 has an effect on the measure. I temporarily disabled the test in revision 1394112. Alex, could you have a look at this? Probably we only need to adjust the test expectations. Michael On 4.10.12 15:55, build...@apache.org wrote: The Buildbot has detected a new failure on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/**oak-trunk/builds/678http://ci.apache.org/builders/oak-trunk/builds/678 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1394094 Blamelist: alexparvulescu,mduerig BUILD FAILED: failed compile sincerely, -The Buildbot
buildbot failure in ASF Buildbot on oak-trunk
The Buildbot has detected a new failure on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/701 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1394523 Blamelist: alexparvulescu BUILD FAILED: failed compile sincerely, -The Buildbot
buildbot success in ASF Buildbot on oak-trunk
The Buildbot has detected a restored build on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/702 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1394528 Blamelist: alexparvulescu Build succeeded! sincerely, -The Buildbot
Re: The destiny of Oak (Was: [RESULT] [VOTE] Codename for the jr3 implementation effort)
+1 to the Bertrand's suggestion same project name, different software name This would keep the community together, but also allows us to have different aims for Jackrabbit (reference impl) and Oak (some level of compliance, not reference impl). On Oct 3, 2012, at 7:23 PM, Bertrand Delacretaz wrote: On Wed, Oct 3, 2012 at 1:53 PM, Tommaso Teofili teof...@adobe.com wrote: ...there is a goal in Oak to be less strict with regard to JCR spec compatibility which, in my opinion, makes a possibly important point of distinction. If this understanding is correct then I think it'd make sense to have separate projects You can have separate software projects/modules in a single Apache project - I agree with others that keeping Oak (the software project/module) within Jackrabbit the Apache project is less risky in terms of community. Saying that Jackrabbit 2 is the JCR reference implementation, and Jackrabbit Oak (or whatever it's called) is a mostly compliant JCR repository is perfectly fine as long as that's clear. -Bertrand
Re: The destiny of Oak (Was: [RESULT] [VOTE] Codename for the jr3 implementation effort)
+1 to the Bertrand's suggestion same project name, different software name cheers stefan
