Hi,
On Thu, Jan 24, 2013 at 3:27 PM, Angela Schreiber wrote:
> it's not for the access control evaluation nor for access
> by path that the query is used... is for the jackrabbit api
> extensions that retrieve access control content by principal.
Ah, I see, thanks!
I used to assume that the per
hi devs
i recently came across quite some new oak code that has
already been marked deprecated... for example the old
index implementations.
would it be possible to get rid of those deprecated classes
and methods? since OAK is a completely new repository
implementation i don't see why we should
There's OAK-436 and OAK-504 already.
Michael
On 24.1.13 13:34, ang...@apache.org wrote:
Author: angela
Date: Thu Jan 24 13:34:49 2013
New Revision: 1437993
URL: http://svn.apache.org/viewvc?rev=1437993&view=rev
Log:
ignore failing test. i will open an issue for that
Modified:
jackrabbit
Hi,
Ah OK. Then the only solution to avoid those indexes is to not support the
feature I guess.
Regards,
Thomas
On 1/24/13 2:27 PM, "Angela Schreiber" wrote:
>hi jukka
>
>it's not for the access control evaluation nor for access
>by path that the query is used... is for the jackrabbit api
>ex
Hi,
Yes, I would also try to avoid using a query to read the ACLs from the
content tree (for multiple reasons: to avoid maintaining indexes, to speed
up access, to simplify caching).
Regards,
Thomas
On 1/24/13 2:22 PM, "Jukka Zitting" wrote:
>Hi,
>
>On Thu, Jan 24, 2013 at 10:11 AM, angela (J
hi jukka
it's not for the access control evaluation nor for access
by path that the query is used... is for the jackrabbit api
extensions that retrieve access control content by principal.
you don't want a repository traversal there... trust me ;-)
angela
On 1/24/13 2:22 PM, Jukka Zitting wrot
Hi,
On Thu, Jan 24, 2013 at 10:11 AM, angela (JIRA) wrote:
> since query is used to retrieve to used retrieve ac content by
> principal, the ac impl should define an property index for the
> rep:principalName defined by rep:ACE node type.
Is it essential for the access control code to use query?
On 24.1.13 12:10, Jukka Zitting wrote:
Hi,
On Thu, Jan 24, 2013 at 1:09 PM, Michael Dürig wrote:
This is caused by the latest jcr-tests snapshot, which includes the fix for
JCR-3499 not being available to the buildbot. Isn't running the Jenkins
build for Jackrabbit enough to deploy these art
Hi,
On Thu, Jan 24, 2013 at 1:09 PM, Michael Dürig wrote:
> This is caused by the latest jcr-tests snapshot, which includes the fix for
> JCR-3499 not being available to the buildbot. Isn't running the Jenkins
> build for Jackrabbit enough to deploy these artefacts?
I suspect that either the Jac
+1
Bart
On Thu, Jan 24, 2013 at 11:24 AM, Jukka Zitting wrote:
> Hi,
>
> A candidate for the Jackrabbit Oak 0.6 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/0.6/
>
> The release candidate is a zip archive of the sources in:
>
> https://svn.apache.org
On 24.1.13 10:24, Jukka Zitting wrote:
Please vote on releasing this package as Apache Jackrabbit Oak 0.6.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.
[X] +1 Release this package as Apache Jackrabbit Oak 0.6
Michael
This is caused by the latest jcr-tests snapshot, which includes the fix
for JCR-3499 not being available to the buildbot. Isn't running the
Jenkins build for Jackrabbit enough to deploy these artefacts?
Michael
On 24.1.13 11:05, build...@apache.org wrote:
The Buildbot has detected a new fai
> Hmm again... ;-)
>
> [INFO] Step 1. Check release cheksum
> [ERROR] Release checksum does not match provided checksum!
I applied Barts fix to the oak release check script. Try again. It works
for me now.
Regards
Marcel
> Please vote on releasing this package as Apache Jackrabbit Oak 0.6.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
[X] +1 Release this package as Apache Jackrabbit Oak 0.6
Regards
Marcel
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/1400
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: osiris_ubuntu
Build Reason: scheduler
Build Source Stamp:
Hmm again... ;-)
[INFO] Step 1. Check release cheksum
[ERROR] Release checksum does not match provided checksum!
Michael
On 24.1.13 10:24, Jukka Zitting wrote:
Hi,
A candidate for the Jackrabbit Oak 0.6 release is available at:
https://dist.apache.org/repos/dist/dev/jackrabbit/oak/0.6/
Hi,
BTW, when building the 0.6 release candidate, you need to also have
the Jackrabbit 2.5.3 release candidate locally installed.
BR,
Jukka Zitting
Hi,
A candidate for the Jackrabbit Oak 0.6 release is available at:
https://dist.apache.org/repos/dist/dev/jackrabbit/oak/0.6/
The release candidate is a zip archive of the sources in:
https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-0.6/
The SHA1 checksum of the arc
On 24/gen/2013, at 10:59, Thomas Mueller wrote:
> Hi,
>
> The current code assumes the index configuration nodes are under
> /oak:index.
Ok thanks for the clarification Thomas, that sounds good for now.
>
> We discussed that index nodes could be local, where the content is, if the
> index onl
Hi all,
maybe that's a silly question but I wonder what is currently considered the
best practice for where to create index nodes.
Do they all have to (or _should_) be under a same (e.g. query:index) node or
rather (as I remember it was discussed) on specific paths? Or it may depend on
the spec
Hi,
On Thu, Jan 24, 2013 at 10:32 AM, Travis-CI wrote:
> View the full build log and details:
> https://travis-ci.org/apache/jackrabbit-oak/builds/4350755
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 262160 b
21 matches
Mail list logo
