From dev-return-33231-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Fri Nov 25 16:36:38 2011 Return-Path: X-Original-To: apmail-jackrabbit-dev-archive@www.apache.org Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0FCEC7C88 for ; Fri, 25 Nov 2011 16:36:38 +0000 (UTC) Received: (qmail 62910 invoked by uid 500); 25 Nov 2011 16:36:37 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 62870 invoked by uid 500); 25 Nov 2011 16:36:37 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 62863 invoked by uid 99); 25 Nov 2011 16:36:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Nov 2011 16:36:37 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of alex.parvulescu@gmail.com designates 209.85.216.170 as permitted sender) Received: from [209.85.216.170] (HELO mail-qy0-f170.google.com) (209.85.216.170) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Nov 2011 16:36:30 +0000 Received: by qyk33 with SMTP id 33so5089404qyk.1 for ; Fri, 25 Nov 2011 08:36:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=o+CCZvnXp4j0JpZPryv9dBvqMrGt8kL5ceOHgTrSi6A=; b=AI1pqg7LDAcyOc5Z+W+mlbo1m5047jiCexCxid70RwOhMPdESq0hub3C+1wfSZoiyt tpdGfr3w1qz7oKp0rVmYSSlx8t9ye1MCsi1qg5zUHh6gkaiVQSx98qf24T+ovO8eeE3g 0KMLeTwAMHzYA7Z3eSXXSvS6fdCxVPr5ZDEWI= MIME-Version: 1.0 Received: by 10.229.64.137 with SMTP id e9mr3855248qci.277.1322238968751; Fri, 25 Nov 2011 08:36:08 -0800 (PST) Received: by 10.229.239.12 with HTTP; Fri, 25 Nov 2011 08:36:08 -0800 (PST) In-Reply-To: References: <712060899.15461322175169102.JavaMail.hudson@aegis> <1585894512.16171322220024198.JavaMail.hudson@aegis> Date: Fri, 25 Nov 2011 17:36:08 +0100 Message-ID: Subject: Re: Jackrabbit-trunk - Build # 1755 - Still Unstable From: Alex Parvulescu To: dev@jackrabbit.apache.org Content-Type: multipart/alternative; boundary=0016e65385520a65e304b291c0af X-Virus-Checked: Checked by ClamAV on apache.org --0016e65385520a65e304b291c0af Content-Type: text/plain; charset=ISO-8859-1 ok, I kinda lost here any ideas how the root node can be sometimes protected? http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/javax/jcr/nodetype/ItemDefinition.html#isProtected() http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.7.2.2 Protected alex On Fri, Nov 25, 2011 at 5:30 PM, Alex Parvulescu wrote: > > Sounds right, though I'm not sure if the importer from JCR-3152 should > take care of adding that mixin automatically. > > Good point, I went into that a bit, and it seems that the importer > (AccessControlImporter) *may* do that in the #start method (which never > gets called). > > The reason can be found under SessionImporter#startNode: > if (parent.getDefinition().isProtected()) > > Here parent is the root node, which seems to fail the test thus makin the > SessionImporter skip the vital #start call. > Indeed checking sImpl.getRootNode().getDefinition().isProtected() yields > false within the test context. > > alex > > On Fri, Nov 25, 2011 at 4:11 PM, Alex Parvulescu < > alex.parvulescu@gmail.com> wrote: > >> I can't get it to pass anymore: >> >> By running >> rm -rf target; mvn -Dtest=AccessControlImporterTest clean test >> on jackrabbit-core (a fresh trunk checkout) >> >> It fails every time: >> >> -------- >> Running org.apache.jackrabbit.core.xml.AccessControlImporterTest >> Tests run: 13, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 14.925 >> sec <<< FAILURE! >> >> Results : >> >> Failed tests: >> testImportRepoACLAtRoot(org.apache.jackrabbit.core.xml.AccessControlImporterTest): >> expected:<1> but was:<0> >> >> Tests in error: >> >> testImportPrincipalBasedACL(org.apache.jackrabbit.core.xml.AccessControlImporterTest): >> Authorizable for 'administrators' already exists: >> >> Tests run: 13, Failures: 1, Errors: 1, Skipped: 0 >> -------- >> >> It is probably related to running the tests concurrently (JCR-3152 >> mentions that as well). >> >> alex >> >> On Fri, Nov 25, 2011 at 3:47 PM, Alex Parvulescu < >> alex.parvulescu@gmail.com> wrote: >> >>> Good question, I don't know what are the assumptions about the root node >>> having some special acl properties. >>> >>> I've only seen the last 3 builds fail because of that. It apparently is >>> a deeper issue. Maybe the proposed fix is not a good idea. >>> >>> alex >>> >>> On Fri, Nov 25, 2011 at 3:32 PM, Jukka Zitting wrote: >>> >>>> Hi, >>>> >>>> On Fri, Nov 25, 2011 at 2:46 PM, Alex Parvulescu >>>> wrote: >>>> > After studying the neighboring tests, namely inspired by >>>> > AccessControlImporterTest#testImportRepoACLAtTestNode >>>> > I think the fix is as simple as adding the missing acl repo info to >>>> the root >>>> > node to #testImportRepoACLAtRoot: >>>> > target.addMixin("rep:RepoAccessControllable"); >>>> >>>> Sounds right, though I'm not sure if the importer from JCR-3152 should >>>> take care of adding that mixin automatically. >>>> >>>> I encountered the same issue before cutting the 2.3.4 release >>>> candidate and came to the same conclusion that the >>>> rep:RepoAccessControllable mixin is not present. Since the problem >>>> doesn't occur consistently across builds I thought that it was due to >>>> some test ordering issue. I fixed the test execution order in revision >>>> 1205866 which seemed to have solved the issue for me, but apparently >>>> that was just a coincidence. >>>> >>>> I wonder if we're still missing something. Why does the test pass >>>> sometimes without the proposed fix? >>>> >>>> BR, >>>> >>>> Jukka Zitting >>>> >>> >>> >> > --0016e65385520a65e304b291c0af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ok, I kinda lost here

any ideas how the root node can be= sometimes protected?


alex

On Fri, Nov 25, 2011 at 5:30 PM, Alex Parvulescu <alex.parvulescu@gmail.com><= /span> wrote:
> Sounds right, though I'm not sure if the im= porter from JCR-3152 should take care of adding that mixin automatically.

Good point, I went into that a bit, and it se= ems that the importer (AccessControlImporter) *may* do that in the #start m= ethod (which never gets called).

The reason can be found under SessionImporter#startNode= :=A0
=A0 =A0 if (parent.getDefinition().isProtected())
=
Here parent is the root node, which seems to fail the test t= hus makin the SessionImporter skip the vital #start call.
Indeed checking sImpl.getRootNode().getDefinition().isProtected() yiel= ds false within the test context.

alex

On Fri, Nov 25, 2011 at 4:= 11 PM, Alex Parvulescu <alex.parvulescu@gmail.com> w= rote:
I can't get it to pass anymore:

By running
=A0 =A0 rm -rf target; mvn -Dtes= t=3DAccessControlImporterTest clean test
on jackrabbit-core (a fresh trunk checkout)

It fails every time:

--------
Running org.apache.jackrabbit.core.xml.AccessControlImporterTest
Tests run: 13, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 14.9= 25 sec <<< FAILURE!

Results :

Failed tests: =A0 te= stImportRepoACLAtRoot(org.apache.jackrabbit.core.xml.AccessControlImporterT= est): expected:<1> but was:<0>

Tests i= n error:=A0
=A0 testImportPrincipalBasedACL(org.apache.jackrabbit.core.xml.AccessC= ontrolImporterTest): Authorizable for 'administrators' already exis= ts:=A0

Tests run: 13, Failures: 1, Errors: 1, Skip= ped: 0
--------

It is probably related to runn= ing the tests concurrently (JCR-3152 mentions that as well).

alex

On Fri, Nov 25, 2011 at 3:47 PM, Alex P= arvulescu <alex.parvulescu@gmail.com> wrote:
Good question, I don't know what ar= e the assumptions about the root node having some special acl properties.

I've only seen the last 3 builds fail because = of that. It apparently is a deeper issue. Maybe the proposed fix is not a g= ood idea.

alex

On Fri, Nov 25, 2011 at 3:32 PM, Jukka Zitting <j= ukka.zitting@gmail.com> wrote:
Hi,

On Fri, Nov 25, 2011 at 2:46 PM, Alex Parvulescu
<alex.par= vulescu@gmail.com> wrote:
> After studying the=A0neighboring=A0tests, namely inspired by
> AccessControlImporterTest#testImportRepoACLAtTestNode
> I think the fix is as simple as adding the missing acl repo info to th= e root
> node to #testImportRepoACLAtRoot:
> =A0 target.addMixin("rep:RepoAccessControllable");

Sounds right, though I'm not sure if the importer from JCR-3152 s= hould
take care of adding that mixin automatically.

I encountered the same issue before cutting the 2.3.4 release
candidate and came to the same conclusion that the
rep:RepoAccessControllable mixin is not present. Since the problem
doesn't occur consistently across builds I thought that it was due to some test ordering issue. I fixed the test execution order in revision
1205866 which seemed to have solved the issue for me, but apparently
that was just a coincidence.

I wonder if we're still missing something. Why does the test pass
sometimes without the proposed fix?

BR,

Jukka Zitting




--0016e65385520a65e304b291c0af--