Re: jackrabbit-oak build #5438: Broken

[Angela Schreiber]

not sure what is wrong. the build works for me even when running the
integration tests.
kind regards
angela

On 14/04/15 12:15, "Travis CI"  wrote:

>Build Update for apache/jackrabbit-oak
>-
>
>Build: #5438
>Status: Broken
>
>Duration: 1493 seconds
>Commit: e6cc4556855a94b0f7262e8f82028c465d49a645 (trunk)
>Author: Angela Schreiber
>Message: OAK-2712 : Possible null-dereference when calling
>ItemImpl#perform
>
>git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1673396
>13f79535-47bb-0310-9956-ffa450edef68
>
>View the changeset:
>https://github.com/apache/jackrabbit-oak/compare/f55727616d7c...e6cc455685
>5a
>
>View the full build log and details:
>https://travis-ci.org/apache/jackrabbit-oak/builds/58413952
>
>--
>sent by Jukka's Travis notification gateway

Re: TokenLoginModule & Spring

[Angela Schreiber]

hi mike

>Unfortunately I needed the User Manager which is only accessible from
>the JCR Repository. And I think their was a 2nd reason, but I don't
>remember it.  So unless there is another way, this seems to be one of
>those decisions you need to make at the start of the project. Either
>you create an OAK repository or a JCR Repository and everything else
>needs to be coded against that API.  Since I initialize the JCR with
>an instance of the Oak, it would be nice to reach in and get the
>underlaying oak repo.  (feature request).

yes... we just didn't have the need for this as we are using it
in a osgi based setup. feel free to create an improvement request
in jira

kind regards
angela

Re: jackrabbit-oak build #5449: Errored

[Angela Schreiber]

should already be fixed... forgot to commit changes
in oak-core utilities required in oak-auth-external.

sorry for the trouble
angela

FW: [FishEye and Crucible] [FishEye] Error processing smart commits for changeset 1673757 in repository jackrabbit

[Angela Schreiber]

hi everyone

can someone tell me why i get this kind of error messages
every now and then when committing changes to oak?

kind regards
angela

On 15/04/15 16:09, "fehost...@atlassian.com" 
wrote:

>
> 
>Automated message: Errors were encountered while processing smart commits
>Due to the following errors, the smart commits were not actioned and will
>need to be performed manually.
>
>Error processing OAK-2674 #hasCapability )
>
>FishEye could not execute the transition "hasCapability" on the issue
>OAK-2674  because
>authentication with the
>JIRA server  failed. Please
>authenticate 
>/authorize?applicationLinkID=5aa69414-a9e9-3523-82ec-879b028fb15b> with
>JIRA from FishEye. You can find more about OAuth configuration in the
>
>documentation 
>entication%28OAuth%29> .
>
>See the 
>documentation 
> for how
>to invoke JIRA Issue Transitions automatically.
>Changeset 
> angela
> changed 1 file
>Apr 15 2015 13:23
>1673757 
>root: 
>on 
>jackrabbit  OAK-2674
>: Fix FindBug Issues (null deref in Session#hasCapability)
>Sent by
>
>Atlassian FishEye  3.7.1 

Re: Copying nodes with access control restrictions

[Angela Schreiber]

hi fernando

i didn't try it out myself but i can imagine the following behaviour:
the check for protection in oak is built on top of the Oak API which
already enforces permissions while afaik the same in jackrabbit
would operate on the item states, which were not access controlled.

we found similar problems before in the oak-jcr layer and i wouldn't
be surprise if there was yet another one :-)

may i kindly ask you to file a JIRA issue with a description on how to
reproduce the issue. even better if you could attach a simple test-case
that illustrates the problem.

for the latter you may extend from AbstractJcrTest (from the tck) or
from AbstractEvaluationTest present in oak-jcr.

kind regards
angela 

On 24/04/15 16:13, "Lemes, Fernando"  wrote:

>
>   Hi guys,
>
>   I'm dealing with some access control problems trying to migrate a
>project from Jackrabbit 2.8.x to Oak 1.0.
>
>   I have a user1 sharing a node with user2, but the user2 cannot copy
>that node (using session.getWorkspace().copy(,)
>method).. the Oak code checks if the parent for the origin node is
>protected, but the user2 doesn't have any permission on that node. Is
>this the expected behavior?
>
>   Regards,
>
>Fernando Lemes da Silva
>Software Engineer - Brazil R&D
>fernando.le...@hp.com
>+55-11-4197-8124
>

Re: special treatment of admin users.

[Angela Schreiber]

hi ian

please note that this is a configuration option that can
be established for _any_ principal name.

if you try to remove access for built-in system principals
the repository will be completely broken.

also i am planning to use exactly this configuration to
make sure our internal _administrators_ group is treated
exactly like the admin user for the very purpose that
i seems impossible that our developers keep a correct
permission setup... half a year after investing weeks
in correcting the setup its broken again :-(

in general i tend to question the use-case you are working
on as it will most definitely come with vulnerabilities
and will make the effective permission setup even more
complicated to understand and impossible to debug/display
in a running repository.

kind regards
angela

 

On 20/05/15 17:44, "Ian Boston"  wrote:

>Hi,
>I am attempting to implement a PoC in oak-core that hides parts of the
>content tree from users based on additional information provided when the
>session is established. I have a working PoC for normal users, but admin
>users still get read-only access to the areas of the tree they should not
>be able to see.
>
>Could someone give me some hints as to where admin bypasses the access
>control enforced by [1] and [2] ?
>
>Best Regards
>Ian
>
>1 
>org.apache.jackrabbit.oak.security.authorization.permission.PermissionProv
>iderImpl
>2 
>org.apache.jackrabbit.oak.security.authorization.permission.CompiledPermis
>sionImpl

Re: special treatment of admin users.

[Angela Schreiber]

Hi Ian

The take of the security team with respect to multi-tenancy is:
Don't try to put that on top of the repository with having the
tenants present in one single JCR workspace.

This is not sensible from a content structure point of view,
a nightmare when it comes to maintenance and most importantly,
you will not be able to properly secure it. Not only from a
permission point of view but also from an application point of
view... we had lengthy discussions about this in the past and
also discussed this with an external security expert during
our yearly security summit. We are pretty sure that it's not
possible.

So, I would really strongly recommend to not try to improve a
broken design that is based on unjustifiable assumptions (such
as e.g. it's only the "content").

Not sure how many years EFA have already been spent on this
but the more people are trying to use the same concept in the
same repository to make their application multi-tenancy-aware
the worse it will become.

I would rather invest the time to implement proper multi-tenancy
with a true, real and complete threat boundary between tenants in the
deepest layer (repository) and you will have all security issues
solved once forever. Anything else won't work and is prone for massive
troubles both from a development and from a legal point of view.

Kind regards
Angela

On 21/05/15 10:08, "Ian Boston"  wrote:

>Hi Angela,
>Thank you for the pointer.
>I assume the area of code that allows administrative users to bypass all
>access control is [1], which gives gives that session [2] granting
>everything without restriction.
>
>The use case is muti-tenancy. The PoC attempts to make Oak natively multi
>tenant. The PoC does not specify configuration or setup. At present it
>introduces a SPI [3] with a default implementation that restricts access
>to
>Oak paths by pattern. The PoC implementation blocks access to
>/tenant//**, if tenantid specified at ContentSession login
>doesn't match .
>
>The PoC, running in Sling, tested with the Sling Explorer application and
>Sling REST API requests works as far as I have tested except for the admin
>user. I have not tested the impact on internal users as they also get [2].
>I also haven't tested the impact on users and groups if they are stored
>under /tenant//**
>
>The patch to Sling requires tenantid to be specified at login, by Host
>header, or on localhost by a request parameter to enable testing. Without
>the tenantid, login fails.
>
>Best Regards
>Ian
>
>
>
>
>1 
>org.apache.jackrabbit.oak.security.authorization.permission.PermissionProv
>iderImpl.isAdmin(Set)
>2 
>org.apache.jackrabbit.oak.security.authorization.permission.AllPermissions
>3
>https://github.com/ieb/jackrabbit-oak/blob/tenant/oak-core/src/main/java/o
>rg/apache/jackrabbit/oak/spi/security/tenant/TenantControlManager.java
>
>
>On 21 May 2015 at 08:13, Angela Schreiber  wrote:
>
>> hi ian
>>
>> please note that this is a configuration option that can
>> be established for _any_ principal name.
>>
>> if you try to remove access for built-in system principals
>> the repository will be completely broken.
>>
>> also i am planning to use exactly this configuration to
>> make sure our internal _administrators_ group is treated
>> exactly like the admin user for the very purpose that
>> i seems impossible that our developers keep a correct
>> permission setup... half a year after investing weeks
>> in correcting the setup its broken again :-(
>>
>> in general i tend to question the use-case you are working
>> on as it will most definitely come with vulnerabilities
>> and will make the effective permission setup even more
>> complicated to understand and impossible to debug/display
>> in a running repository.
>>
>> kind regards
>> angela
>>
>>
>>
>> On 20/05/15 17:44, "Ian Boston"  wrote:
>>
>> >Hi,
>> >I am attempting to implement a PoC in oak-core that hides parts of the
>> >content tree from users based on additional information provided when
>>the
>> >session is established. I have a working PoC for normal users, but
>>admin
>> >users still get read-only access to the areas of the tree they should
>>not
>> >be able to see.
>> >
>> >Could someone give me some hints as to where admin bypasses the access
>> >control enforced by [1] and [2] ?
>> >
>> >Best Regards
>> >Ian
>> >
>> >1
>> 
>>>org.apache.jackrabbit.oak.security.authorization.permission.PermissionPr
>>>ov
>> >iderImpl
>> >2
>> 
>>>org.apache.jackrabbit.oak.security.authorization.permission.CompiledPerm
>>>is
>> >sionImpl
>>
>>

Re: special treatment of admin users.

[Angela Schreiber]

hi ian

yes... that's what I am saying... with a few correction,
where i you might have got me wrong:

1) 
i don't think we should use JCR workspaces for the multi-tenancy
but rather aim for 'similar' concept with multi-tenancy setup on Oak,
where each tenants gets it's own root-node and everything below
without the troublesome parts (multitenancy-wise) when it comes
to JCR workspaces (e.g. shared version store).

that would obviously also required a POC as there are for sure
things that need a closer look... but IMHO this would be a
promising approach that would allow for a real/proper threat
boundary between tenants from a security point of view.

apart from the trust boundary we could just get rid of those terrible
multiple tenant-setups spread throughout the repository content,
which are to become unmanageable with more people trying to make
their app multi-tenant enabled.

2)
after all I think it would make more sense if you invested research
and time in a real multi-tenancy setup at the node store level
as described above than trying to fix the existing broken design.
after all you started to work on oak already, right? just needed
to step one level deeper... it's still oak-core :-)

as you may know the security team recently had another session
listing problems with the current setup and discussing how it
would make sense from a security point of view. from the information
it got there from my security-colleagues attending the Adobe internal
multi-tenancy calls, i understood that the first next step of the
mt-working-group would be to come up with a threat-model including
tenants... maybe that was a misunderstanding?

3)
maybe it would make sense to have internal call with the security
team, to bring everyone on the same page both from a expected
next steps and a security point of view.

wdyt? 

kind regards
angela


On 21/05/15 11:09, "Ian Boston"  wrote:

>Hi Angela,
>
>So you are saying that there is no point in pursuing this PoC at the Tree
>level and I should stop what I am doing and wait for the Oak team to
>implement Workspaces or some other low level mechanism which was closed
>"later" in February 2013 ?
>
>I agree with everything you have said, having experienced first hand the
>issues you have referenced, which is why I have been asked to work on this
>PoC, in a personal branch, in a fork of Oak on GitHub.
>
>Best Regards
>Ian
>
>
>On 21 May 2015 at 09:25, Angela Schreiber  wrote:
>
>> Hi Ian
>>
>> The take of the security team with respect to multi-tenancy is:
>> Don't try to put that on top of the repository with having the
>> tenants present in one single JCR workspace.
>>
>> This is not sensible from a content structure point of view,
>> a nightmare when it comes to maintenance and most importantly,
>> you will not be able to properly secure it. Not only from a
>> permission point of view but also from an application point of
>> view... we had lengthy discussions about this in the past and
>> also discussed this with an external security expert during
>> our yearly security summit. We are pretty sure that it's not
>> possible.
>>
>> So, I would really strongly recommend to not try to improve a
>> broken design that is based on unjustifiable assumptions (such
>> as e.g. it's only the "content").
>>
>> Not sure how many years EFA have already been spent on this
>> but the more people are trying to use the same concept in the
>> same repository to make their application multi-tenancy-aware
>> the worse it will become.
>>
>> I would rather invest the time to implement proper multi-tenancy
>> with a true, real and complete threat boundary between tenants in the
>> deepest layer (repository) and you will have all security issues
>> solved once forever. Anything else won't work and is prone for massive
>> troubles both from a development and from a legal point of view.
>>
>> Kind regards
>> Angela
>>
>> On 21/05/15 10:08, "Ian Boston"  wrote:
>>
>> >Hi Angela,
>> >Thank you for the pointer.
>> >I assume the area of code that allows administrative users to bypass
>>all
>> >access control is [1], which gives gives that session [2] granting
>> >everything without restriction.
>> >
>> >The use case is muti-tenancy. The PoC attempts to make Oak natively
>>multi
>> >tenant. The PoC does not specify configuration or setup. At present it
>> >introduces a SPI [3] with a default implementation that restricts
>>access
>> >to
>> >Oak paths by pattern. The PoC implementation blocks access to
>> >/tenant//**, if tenantid specified at Con

Re: special treatment of admin users.

[Angela Schreiber]

hi ian

sorry, if my reply looked harsh to you.

i really don't care about the package names of a multi-tenancy
POV :-) my take is that we get all security concerns (and a decent)
content structure for free, if we managed to introduce the tenant
separation above the Oak Root or JCR root node.

not sure i fully understand the very details of your last summary
but it seems to be closer to what i envision:

i could think of a tenant separation even above the Oak Root
and thus not having to think about the tenants when Oak Tree(s)
come into the game.

in other words: after having obtained the ContentSession
and the Root object therein, you already had a totally isolated
tenant, with a regular (JCR) root node, a separate user tree,
a separate admin-user (having administrative-access just on that
Root/tenant), it's own permission evaluation, a unique-indices,
and jcr:system... everything for just that very tenant.

from an Oak/JCR perspective there was in such a setup no
way to cross the tenant boundary and each tenant behaved
from security point of view like an Oak repo now. so, it
was only if you looked at the persistence layer that there
were multiple tenants.

that's my architectural vision of a multi-tenant oak repository
without having a POC at hand. and obviously still a lot of
question marks here and there ... :-)

let's organise a meeting/call to also have the other team
members on board.

kind regards
angela



On 21/05/15 19:41, "Ian Boston"  wrote:

>Hi Angela,
>
>
>On 21 May 2015 at 17:53, Angela Schreiber  wrote:
>
>> hi ian
>>
>> yes... that's what I am saying...
>
>
>Ok, thats fine I guessed right this morning when I abandoned my work in
>progress.
>
>
>> with a few correction,
>> where i you might have got me wrong:
>>
>> 1)
>> i don't think we should use JCR workspaces for the multi-tenancy
>> but rather aim for 'similar' concept with multi-tenancy setup on Oak,
>> where each tenants gets it's own root-node and everything below
>> without the troublesome parts (multitenancy-wise) when it comes
>> to JCR workspaces (e.g. shared version store).
>>
>> that would obviously also required a POC as there are for sure
>> things that need a closer look... but IMHO this would be a
>> promising approach that would allow for a real/proper threat
>> boundary between tenants from a security point of view.
>>
>> apart from the trust boundary we could just get rid of those terrible
>> multiple tenant-setups spread throughout the repository content,
>> which are to become unmanageable with more people trying to make
>> their app multi-tenant enabled.
>>
>
>agreed, I started a new branch along those lines, which I just finished
>with the refactor. It "taints" Root implementations and Tree
>implementations with the tenant and asserts the validity of child
>instances
>when adding more to a tainted tree.
>
>In one sense each Root is different, but by tainting it allows all tainted
>roots to share common areas of the Tree rather than having to know what to
>mount and how.
>
>Its not committed, as I haven't proven it works yet.
>
>
>>
>> 2)
>> after all I think it would make more sense if you invested research
>> and time in a real multi-tenancy setup at the node store level
>> as described above than trying to fix the existing broken design.
>> after all you started to work on oak already, right? just needed
>> to step one level deeper... it's still oak-core :-)
>>
>
>I was at the Root/Tree level already, but I could not see how admin was
>bypassing that level, so I put more checks in the permissions
>implementation, and admin still got past, hence asking for help on the
>list. I have no desire to mess in any package with the word "security" in
>it.
>
>There are some areas that I have doubts about, as many of the Validators
>perform operations on Trees they create out of the blue not connected to
>any session. For the moment I am giving them a system context and logging
>the location.
>
>
>>
>> as you may know the security team recently had another session
>> listing problems with the current setup and discussing how it
>> would make sense from a security point of view. from the information
>> it got there from my security-colleagues attending the Adobe internal
>> multi-tenancy calls, i understood that the first next step of the
>> mt-working-group would be to come up with a threat-model including
>> tenants... maybe that was a misunderstanding?
>>
>
>I am not aware of those meetings, I haven't been involved in the
>mt-working-group for about 18 months as I ha

Re: ImmutableTreeTest.testHiddenExists , confusion.

[Angela Schreiber]

hi ian

here is my take on it:

- the ImmutableTree is just a tiny wrapper around the regular
  non-secured Nodestate for the sake of allowing to make use
  of the hierarchy operations that are missing in the NodeState
  interface.
  those immutable (read-only) trees are meant to be used for
  oak internal low-level usages where keeping track of the
  parent and the path is required although the operations are
  meant to be performed on the un-secured NodeState, which
  usually requires access to hidden items as well.

- the MutableTree is that actual implementation of the Tree
  interface that is exposed when operating on the Oak API
  s.str. This one *must never* expose the hidden items.

hope that helps
angela

On 03/06/15 12:50, "Ian Boston"  wrote:

>Hi,
>
>I am confused how hidden trees work in MutableTree and ImmutableTree.
>
>The ImmutableTreeTesttestHiddenExists asserts that a hidden node from an
>ImmutableTree will return true() to exists, and yet the same node from a
>MuttableTree is hard coded to return false to exists().
>
>
>Is this correct ? If so, why ?
>
>
>Some checks I added to the test to investigate are below.
>
>assume I have a node ':hidden' which I believe has been committed to the
>NodeStore in use.
>
>- check1 --
>
>NodeState testNode2 = store.getRoot().getChildNode(":hidden");
>boolean testNode2Exists = testNode2.exists();
>
>
>testNode2 is a DocumentNodeState "{ path: '/:hidden', rev:
>'r14db8ebf37d-0-1', properties: '{}' }"
>testNode2Exists == true
>
>
>- check2 --
>
>Tree mutableTree  = session.getLatestRoot().getTree("/");
>   Tree hiddenTree = mutableTree.getChild(":hidden");
>   boolean hiddenTreeExists = hiddenTree.exists();
>
>hiddenTree is a HiddenTree "/:hidden: {}"
>hiddenTreeExists == false
>
>hiddenTree is a HiddenTree because mutableTree.getChild looks at the name
>and hard codes a HiddenTree for anything beginning with ':'
>
>
>--- check3 
>
>   ImmutableTree immutable = new ImmutableTree(state);
>   ImmutableTree hiddenChild = immutable.getChild(":hidden");
>   boolean childExists = hiddenChild.exists();
>hiddenChild is an ImmutableTree,
>childExists == true
>
>The unit test does:
>
>@Test
>public void testHiddenExists() {
>ImmutableTree hidden = immutable.getChild(":hidden");
>assertTrue(hidden.exists());
>}
>
>BTW: I the modified NodeStore I am working on, check3 childExists returns
>false, failing the test, hence the question. I would like to understand
>why
>the test is correct so I can find the bug in my code.
>
>
>Best Regards
>Ian

Re: Access control logging

[Angela Schreiber]

i commented on the issue.

kind regards
angela

On 12/06/15 02:29, "Alexander Klimetschek"  wrote:

>https://issues.apache.org/jira/browse/OAK-2981
>
>wdyt?
>
>Alex

Re: trunk build is failing due baseline plugin complaining

[Angela Schreiber]

hi julian

see 
- OAK-2006 
- OAK-1956 

i just forgot to commit the package-info files in r1685806
and fixed it again in 1685811.

if it fails with your local changes you probably modified
some exported API and need to adjust the versions.

hth
angela

On 16/06/15 15:52, "Julian Reschke"  wrote:

>(see subject -- what's going on here???)

Re: oak-exercise on maven

[Angela Schreiber]

hi davide

no objection from my side. it doesn't need to be deployed; it's
sufficient to just build it and thus spot any kind of
compile time incompatibilities.

i created those exercises for an internal security training and
they have proven to be really helpful. so, i want to make this
available for everyone interested and will continue working
on this... in particular think about a better verification step
other than just having the exercise test-cases pass ;-)

kind regards
angela

On 29/06/15 15:37, "Davide Giannella"  wrote:

>I just realised that oak-exercises is deployed on maven on release.
>
>https://repository.apache.org/content/repositories/releases/org/apache/jac
>krabbit/oak-exercise/
>
>I think it's better, for disk saving and deploying time to skip this
>artifact from the deploy phase.
>
>Anyone against it?
>
>Davide
>
>

Re: Utility method for show time duration in words

[Angela Schreiber]

hi chetan

tobi already added something along that line to ConfigurationParameters.
-> see ConfigurationParameters.Milliseconds
afaik it's the opposite (converting human readable to milis), so we might
also think of extending that one.

regards
anglea

On 14/07/15 11:25, "Chetan Mehrotra"  wrote:

>Hi,
>
>At times I feel a need for a utility method which can convert time in
>mills to words for logs and JMX
>
>There are two options I see
>
>1. commons-lang DurationFormatterUtils [1] - Adding dependency to
>whole of commons-lang might not make sense. So we can probably copy
>it. It though depends on others common lang classes so copying would
>be tricky
>
>2. Guava Stopwatch private method [2] - Guava Stopwatch internally has
>such a method but its not exposed. Probably we can copy that and
>expose that in oak-commons.
>
>Thoughts?
>
>Chetan Mehrotra
>[1] 
>https://github.com/apache/commons-lang/blob/master/src/main/java/org/apach
>e/commons/lang3/time/DurationFormatUtils.java
>[2] 
>https://github.com/google/guava/blob/master/guava/src/com/google/common/ba
>se/Stopwatch.java#L216

Re: [discuss] handling of 'wish list' issues - introduce 'wish list' fix version?

[Angela Schreiber]

why not simply marking it as 'unscheduled'? IMO that pretty much
expresses that this is is not yet scheduled but still considered
a valid improvement/bug that we want to address at some point.

i only resolve issues 'later' or 'wontfix' that i am confident
that will never be fixed.

adding a 'wish list' fix version will just be another huge container
that we hardly ever look at and i would find it hard to understand
the difference between 'unscheduled' and 'wish list'.

if something is on your wishlist, i would suggest you assign the
issue to yourself in order to keep track of it (compared to the
whole bunch of other unscheduled issues). or flag it with a
label that allows you to find all your wishes.

so, rather -1 from my side.

kind regards
angela

On 29/07/15 08:58, "Stefan Egli"  wrote:

>Hi,
>
>Just came across a ticket [0] that has no urgent priority to be fixed in
>1.3
>but would be a good candidate to be put into the general 'wish list pod'.
>
>Now currently we seem to handle such cases by just closing the ticket.
>This
>imv has the downside of it getting completely lost and forgotten.
>
>We could thus introduce a new 'wish list' fix version that can be set on
>those tickets instead of just closing them.
>
>Wdyt?
>
>Cheers,
>Stefan
>--
>https://issues.apache.org/jira/browse/OAK-2613
>
>

jackrabbit version set to 2.10.2-SNAPSHOT

[Angela Schreiber]

hi oak devs

in order to be able to complete OAK-3160 [0] and continue my
work on OAK-3160 [1], i will set the jackrabbit version in oak trunk
to latest snapshot version to pick up the extensions added to the
Jackrabbit API.

so, you might have to get the latest jackrabbit version once
you update to the lastest trunk..

sorry for any inconvenience this might cause.

kind regards
angela


[0] https://issues.apache.org/jira/browse/OAK-3160
[1] https://issues.apache.org/jira/browse/OAK-3160

Re: svn commit: r1693270 - in /jackrabbit/oak/trunk: oak-authorization-cug/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/cug/ oak-authorization-cug/src/test/java/org/apache/jackra

[Angela Schreiber]

oh... my bad. it should obviously be the Text utility from jcr-commons
not the one from the test! sorry...

angela

On 04/08/15 15:47, "Michael Dürig"  wrote:

>
>
>On 29.7.15 4:21 , ang...@apache.org wrote:
>> Author: angela
>> Date: Wed Jul 29 14:21:18 2015
>> New Revision: 1693270
>>
>> URL: http://svn.apache.org/r1693270
>> Log:
>> OAK-3160 - Implement Session.hasPermission(String, String...) and
>>support for additional actions,
>> OAK-2008 :  authorization setup for closed user groups (WIP)
>>
>
>>
>> Modified: 
>>jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/
>>session/SessionImpl.java
>> URL: 
>>http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-jcr/src/main/java/o
>>rg/apache/jackrabbit/oak/jcr/session/SessionImpl.java?rev=1693270&r1=1693
>>269&r2=1693270&view=diff
>> 
>>=
>>=
>> --- 
>>jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/
>>session/SessionImpl.java (original)
>> +++ 
>>jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/
>>session/SessionImpl.java Wed Jul 29 14:21:18 2015
>> @@ -69,6 +69,7 @@ import org.apache.jackrabbit.oak.jcr.ses
>>   import org.apache.jackrabbit.oak.jcr.xml.ImportHandler;
>>   import 
>>org.apache.jackrabbit.oak.spi.security.authentication.ImpersonationCreden
>>tials;
>>   import 
>>org.apache.jackrabbit.oak.spi.security.authorization.permission.Permissio
>>ns;
>> +import org.apache.jackrabbit.test.api.util.Text;
>
>This breaks upstream applications as jackrabbit-jcr-tests (which
>contains o.a.j.test.api.util.Text) is declared as optional.
>
>Michael

Re: jackrabbit-oak build #6116: Broken

[Angela Schreiber]

changes made with OAK-3170 require the API extensions in jackrabbit-api
made 
with revision 1694048. i therefore expect that build to pass as soon as it
picks that rev.

br
angela





On 04/08/15 15:59, "Travis CI"  wrote:

>Build Update for apache/jackrabbit-oak
>-
>
>Build: #6116
>Status: Broken
>
>Duration: 642 seconds
>Commit: c10c7a6ed1c52a4d3e37b9df7ce576502fc5ddea (trunk)
>Author: Angela Schreiber
>Message: OAK-3170 : Implement Group extensions as proposed in JCR-3880
>
>git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1694049
>13f79535-47bb-0310-9956-ffa450edef68
>
>View the changeset:
>https://github.com/apache/jackrabbit-oak/compare/075cd64409cd...c10c7a6ed1
>c5
>
>View the full build log and details:
>https://travis-ci.org/apache/jackrabbit-oak/builds/74065598
>
>--
>sent by Jukka's Travis notification gateway

Re: jackrabbit-oak build #6116: Broken

[Angela Schreiber]

hm... according to the jackrabbit log r1694048 (JCR-3880)
was before r1694063 (JCR-3896 - Release Jackrabbit 2.10.2)

but oak trunk is still on 2.10.2-SNAPSHOT (and not yet on 2.10.2)
not sure if setting to 2.10.3-SNAPSHOT was really needed.

kind regards
angela

On 04/08/15 17:12, "Julian Reschke"  wrote:

>On 2015-08-04 17:04, Julian Reschke wrote:
>> On 2015-08-04 16:49, Angela Schreiber wrote:
>>> changes made with OAK-3170 require the API extensions in jackrabbit-api
>>> made
>>> with revision 1694048. i therefore expect that build to pass as soon
>>> as it
>>> picks that rev.
>>>
>>> br
>>> angela
>>
>> I have the same problem locally, despite having updated and built
>> jackrabbit trunk.
>>
>> Am I missing something else I need to do?
>>
>> Best regards, Julian
>
>...probably in the meantime jackrabbit trunk is 2.10.3-SNAPSHOT while
>oak refers to 2.10.2-SNAPSHOT...?

Re: [rep:User] autosave when bulk creating users

[Angela Schreiber]

hi nicolas

On 31/07/15 10:48, "Nicolas Peltier"  wrote:

>Hi,
>
>i¹ve seen that UserManager.autosave was an unsupported operation, and
>thus using LDAP sync with many users generates a save at each user/group
>creation which makes the sync very slow.

not sure i get that if autosave was enabled _every_ single
operation on the user management API would trigger a session.save.
isn't that just what you wish to avoid?

btw: autosave is not supported by default, but for backwards compatibility
it can be enabled... but it's really just meant for those cases where
this is inevitable.

>Installing a package of users is much quicker, so i¹m wondering if there
>is a way to create user with an API without saving at each user creation,
>group creation, membership change?

whenever you create or modify a user/group using regular user management
API the changes are not autosaved by default and it's up to the
caller to persist the changes by calling Session.save().

or do you specifically mean the creation of a user in the context of
sync from LDAP (or some other external identity provider)?

>Thanks for your answers,

i guess you need to clarify your question again...

kind regards
angela

>Nicolas
>
>

Re: [rep:User] autosave when bulk creating users

[Angela Schreiber]

hi nicolas

>>whenever you create or modify a user/group using regular user management
>> API the changes are not autosaved by default and it's up to the
>> caller to persist the changes by calling Session.save().
>i didn¹t know that, great.

see also
http://jackrabbit.apache.org/oak/docs/security/user.html

>
>> or do you specifically mean the creation of a user in the context of
>> sync from LDAP (or some other external identity provider)?
>i¹m reusing DefaultSyncHandler¹s sync mechanism together with ldap
>identity provider, and was blaming something in there writing too
>frequently. 
>I guess then problem is between oak¹s code & the result i get = between
>my keyboard and my chair.

i am not too familiar with the sync mechanism... but looking just
quickly at the code it seems that it persists the sync of each user/group.
that looks reasonable to me (even if it comes with some Root.commit()
overhead) as it allows to specifically retry or revert the changes
made during the sync of one single account. that's the defensive
way of minimising the unexpected behaviour for the consumer in case
of failure.

on the other hand you might argue that the default should be success
and that in those cases less frequent calls to persist the changes
might work as well and was probably faster.

not sure what the right answer would be here... in any case: it's not
an autosave of the user management implementation but a conscious
decision of the sync-handler to frequently persist the changes :-)

hope that helps

>Thanks Angela for your answers!

you are welcome.
angela

>
>Nicolas
>

Re: [rep:User] autosave when bulk creating users

[Angela Schreiber]

hi nicolas

>>i am not too familiar with the sync mechanism... but looking just
>> quickly at the code it seems that it persists the sync of each
>>user/group.
>> that looks reasonable to me (even if it comes with some Root.commit()
>> overhead) as it allows to specifically retry or revert the changes
>> made during the sync of one single account. that's the defensive
>> way of minimising the unexpected behaviour for the consumer in case
>> of failure.
>> 
>> on the other hand you might argue that the default should be success
>> and that in those cases less frequent calls to persist the changes
>> might work as well and was probably faster.
>mmm interesting, yeah i might argue that :-)

:-)

>and that we could probably in case of an error ³replay² user/group sync
>persisting one by one,
>from the last successful save. Will have a look.

i don't think this is feasible. you will have to revert everything
again and start over again. in particular merge conflicts will be
impossible to sort out once you get them with a lot of different
changes made.

but anyway: there is always a balance to find and i am not familiar
with those very design details in the sync handler... i am just reading the
code and trying to explain. for sure tobi provide more insight here.

kind regards
angela 

>
>Thanks a lot,
>Nicolas

Re: Copy jackrabbit-webapp module to Oak as oak-webapp

[Angela Schreiber]

hi

On 06/08/15 12:11, "Michael Dürig"  wrote:
>On 6.8.15 11:59 , Chetan Mehrotra wrote:
>> I understand the concern here Michael. But then I am not sure on the
>> best way forward. It has mostly jsp and couple of classes. The class
>> would need to be adapted to work with Oak and we would also need to
>> remove dependency on jackrabbit-core as it would not be possible to
>> support both (due to conflicting lucene version). if you have any
>> suggestion on how to structure it that would be helpful. If its not ok
>> to put the sample here I can remove it but I do not see a simple way
>> to structure it without copying
>
>I agree this being difficult. Do we at least have an idea of the
>benefit/future cost ratio of this? How do we maintain it (i.e. make sure
>both copies get all future fixes)? Is this an official part of Oak or
>rather an example? In the latter case, can we make this more explicit?

if it's an example we can put it to oak-example.
angela

>
>Michael

Re: Modularization

[Angela Schreiber]

hi thomas

hey... we already have 2 modules for access control. one
being just an optional implementation (module) that could be
plugged additionally once we have support for composite
authorization setup.

as far as i understood every single proposal and approach
that was made over the last couple of years to modularise Oak,
it always seemed perfectly reasonable to me. so far nobody was
asking for ripping apart all of the oak-core layer s.str
(the meat of the hamburger if you wish)... not mentioning that
this wouldn't be possible right now due to the plugins mess
we are having for the various JCR special areas.

what we have been discussing over and over again and what everyone
keeps proposing as a first step is: modularise based on the layers
that we originally designed and agreed upon.

having said that, i would like to remind you that we actually had
that separation of layers in the original setup where the
persistence layer was in a separate mk-api and mk-impl
module... it's only due to political whatsoever that we found
ourselves with abandoned mk-persistence modules and a new node
store persistence model that is awkwardly 'hidden' in oak-core.

so, my goal would be to restored the separation again now that
we officially got rid of the abandoned code.

i see to ways to get there:

A) move the node store parts out of oak-core because they don't belong
there
   as they are a different layer in our original
   - jcr (top-bread)
   - core (meat with all the validation)
   - persistence (bottom-bread, aka mk)
   design

B) move the rest out of oak-core and 'redefine' the name 'oak-core' to be
   just the persistence (bottom-bread) but no longer representing the meat.

from an architecture point of view A) looks like the desirable
solution for me... B) looks really confusing to me but might be suited
to address the concerns raised by those that fear that the node store
implementations are too unstable and too heavily worked on.

my concern with B) is that we will end up just doing what we currently
try to avoid:  heavily refactor and restructure the meat-layer and
possibly ending up with way too many modules.

as far as access control (and the other security related areas)
is concerned, you can be assured that i will keep an eye on it...
don't worry :-)

kind regards
angela

On 06/08/15 12:25, "Thomas Mueller"  wrote:

>Hi,
>
>>
>>OTOH if one module does storage and indexing and access control and
>>monitoring for example it's too much IMO, that should ideally be four
>>modules.
>
>Again, what would be the benefit of having many Maven projects? Besides, I
>don't think we could easily move all of access control to one Maven
>project, because access control is a cross-cutting concern. Monitoring, I
>don't think we do much of that right now.
>
>>in Sling we are only testing very few combinations,
>>actually just one combination per release.
>
>Good to know! I still don't quite understand why you have many projects
>then... what is the driver to create smaller and smaller projects?
>
>Regards,
>Thomas
>

build failure due to oak-pojosr ??

[Angela Schreiber]

hi

i get the following failures in oak-pojosr. is it only me?
anybody working on this?

Running org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 11.447 sec
<<< FAILURE!
fullTextSearch(org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest)  Time
elapsed: 11.442 sec  <<< ERROR!
java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy14.shutdown(Unknown Source)
at org.apache.jackrabbit.api.JackrabbitRepository$shutdown.call(Unknown
Source)
at 
org.apache.jackrabbit.oak.run.osgi.AbstractRepositoryFactoryTest.tearDown(A
bstractRepositoryFactoryTest.groovy:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:5
7)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
l.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod
.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.
java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.j
ava:42)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:46)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.ja
va:68)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.ja
va:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java
:252)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provid
er.java:141)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:
112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:5
7)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
l.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(Reflec
tionUtils.java:189)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(Provi
derFactory.java:165)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFac
tory.java:85)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBoot
er.java:115)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:5
7)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
l.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory$RepositoryProxy
.invoke(OakOSGiRepositoryFactory.java:396)
... 34 more
Caused by: java.lang.IllegalStateException: Service already unregistered.
at 
org.apache.felix.connect.felix.framework.ServiceRegistrationImpl.unregister
(ServiceRegistrationImpl.java:128)
at 
org.apache.jackrabbit.oak.osgi.OsgiWhiteboard$1.unregister(OsgiWhiteboard.j
ava:75)
at 
org.apache.jackrabbit.oak.spi.whiteboard.CompositeRegistration.unregister(C
ompositeRegistration.java:43)
at org.apache.jackrabbit.oak.Oak$6.close(Oak.java:640)
at org.apache.commons.io.IOUtils.closeQuietly(IOUtils.java:303)
at 
org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.shutdown(Repository
Impl.java:308)
... 39 more

Running org.apache.jackrabbit.oak.run.osgi.NodeStoreConfigTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.129 sec
Running org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactoryTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.369 sec
<<< FAILURE!
testRepositoryTar(org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFacto
ryTest)  Time elapsed: 6.368 sec  <<< ERROR!
java.lang.reflect.UndeclaredThrowableException
   

Re: OAK-3201 - Working on it

[Angela Schreiber]

done

yours
angela

On 10/08/15 12:20, "Francesco Mari"  wrote:

>Hi,
>
>I'm currently working on OAK-3201. Feel free to assign the issue to
>me, since I don't have enough privileges to do it myself.
>
>Thanks,
>
>Francesco

Re: JR snapshot dependency

[Angela Schreiber]

hi Tommaso

the reason why it is failing now is IMO due to reverting
api extensions from the 2.10 branch and moving them to
jackrabbit 2.11.0-SNAPSHOT without adjusting the Oak dependencies.

without the SNAPSHOT dependencies i would not have been able
to implement and commit the feature in Oak you have been
asking for ;-)

maybe Unico can take care of this and fix Oak trunk accordingly?

kind regards
Angela

On 11/08/15 16:47, "Tommaso Teofili"  wrote:

>Hi all,
>
>since today I am getting a failed build on trunk on the oak-blob-cloud
>module with the following:
>
>[ERROR] Failed to execute goal on project oak-blob-cloud: Could not
>resolve
>dependencies for project
>org.apache.jackrabbit:oak-blob-cloud:bundle:1.4-SNAPSHOT: The following
>artifacts could not be resolved:
>org.apache.jackrabbit:jackrabbit-jcr-commons:jar:2.10.3-SNAPSHOT,
>org.apache.jackrabbit:jackrabbit-data:jar:2.10.3-SNAPSHOT,
>org.apache.jackrabbit:jackrabbit-data:jar:tests:2.10.3-SNAPSHOT: Could not
>find artifact
>org.apache.jackrabbit:jackrabbit-jcr-commons:jar:2.10.3-SNAPSHOT
>
>I have realized this is related to the snapshot JR dependency set in
>oak-parent.
>
>I think it'd be nice to avoid such unreleased versions of JR (and snapshot
>dependencies in general) in the future.
>
>Regards,
>
>Tommaso

Re: svn commit: r1703758 - in /jackrabbit/oak/trunk: oak-authorization-cug/src/test/java/org/apache/jackrabbit/oak/spi/security/authorization/cug/impl/ oak-core/src/main/java/org/apache/jackrabbit/oak

[Angela Schreiber]

hi francesco

thanks a lot for taking care of this issue! very much appreciated.

just a few comments:
as just discussed in private required configurationin
RandomAuthorizableNodeName
is mandatory. please don't remove it... just because CQ has this
configured by default doesn't mean that it's the default in oak
(it isn't for backwards compatibility as you can see in the
documentation).

second, i feel a bit uneasy about the compability break in
SecurityProviderImpl
which is a public class and exported... let's discuss that again
next week.

and finally... the SecurityProviderRegistration should have annotations
for the public methods that are nowhere used inside oak (SuppressWarning).
can you add those?

thanks a lot and have a nice weekend
angela 

On 18/09/15 09:34, "f...@apache.org"  wrote:

>Author: frm
>Date: Fri Sep 18 07:34:53 2015
>New Revision: 1703758
>
>URL: http://svn.apache.org/viewvc?rev=1703758&view=rev
>Log:
>OAK-3201 - Prevent SecurityProviderImpl to register unless its required
>dependencies are accessible
>
>Added:
>
>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/secu
>rity/Preconditions.java   (with props)
>
>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/secu
>rity/SecurityProviderRegistration.java   (with props)
>
>jackrabbit/oak/trunk/oak-pojosr/src/test/groovy/org/apache/jackrabbit/oak/
>run/osgi/SecurityProviderRegistrationTest.groovy
>Modified:
>
>jackrabbit/oak/trunk/oak-authorization-cug/src/test/java/org/apache/jackra
>bbit/oak/spi/security/authorization/cug/impl/CugSecurityProvider.java
>
>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/secu
>rity/SecurityProviderImpl.java
>
>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/secu
>rity/package-info.java
>
>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/secu
>rity/user/RandomAuthorizableNodeName.java
>
>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/
>security/authentication/token/CompositeTokenConfiguration.java
>
>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/
>security/authentication/token/package-info.java
>
>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/
>security/principal/CompositePrincipalConfiguration.java
>
>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/
>security/principal/package-info.java
>jackrabbit/oak/trunk/oak-pojosr/pom.xml
>
>Modified: 
>jackrabbit/oak/trunk/oak-authorization-cug/src/test/java/org/apache/jackra
>bbit/oak/spi/security/authorization/cug/impl/CugSecurityProvider.java
>URL: 
>http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-authorization-cug/sr
>c/test/java/org/apache/jackrabbit/oak/spi/security/authorization/cug/impl/
>CugSecurityProvider.java?rev=1703758&r1=1703757&r2=1703758&view=diff
>==
>
>--- 
>jackrabbit/oak/trunk/oak-authorization-cug/src/test/java/org/apache/jackra
>bbit/oak/spi/security/authorization/cug/impl/CugSecurityProvider.java
>(original)
>+++ 
>jackrabbit/oak/trunk/oak-authorization-cug/src/test/java/org/apache/jackra
>bbit/oak/spi/security/authorization/cug/impl/CugSecurityProvider.java Fri
>Sep 18 07:34:53 2015
>@@ -33,12 +33,8 @@ final class CugSecurityProvider extends
> composite.setDefaultConfig(authorizationConfiguration);
> composite.addConfiguration(new CugConfiguration(this));
> composite.addConfiguration(authorizationConfiguration);
>-((CugSecurityProvider)
>this).bindAuthorizationConfiguration(composite);
>+setAuthorizationConfiguration(composite);
> }
> }
> 
>-@Override
>-protected void bindAuthorizationConfiguration(@Nonnull
>AuthorizationConfiguration reference) {
>-super.bindAuthorizationConfiguration(reference);
>-}
> }
>\ No newline at end of file
>
>Added: 
>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/secu
>rity/Preconditions.java
>URL: 
>http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/main/java/o
>rg/apache/jackrabbit/oak/security/Preconditions.java?rev=1703758&view=auto
>==
>
>--- 
>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/secu
>rity/Preconditions.java (added)
>+++ 
>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/secu
>rity/Preconditions.java Fri Sep 18 07:34:53 2015
>@@ -0,0 +1,115 @@
>+/*
>+ * Licensed to the Apache Software Foundation (ASF) under one or more
>+ * contributor license agreements.  See the NOTICE file distributed with
>+ * this work for additional information regarding copyright ownership.
>+ * The ASF licenses this file to You under the Apache License, Version
>2.0
>+ * (the "License"); you may not use this file except in compliance with
>+

Re: svn commit: r1703758 - in /jackrabbit/oak/trunk: oak-authorization-cug/src/test/java/org/apache/jackrabbit/oak/spi/security/authorization/cug/impl/ oak-core/src/main/java/org/apache/jackrabbit/oak

[Angela Schreiber]

hi francesco

thanks a lot for the update and your suggestions.

in particular i agree that exposing the security provider impl
is really bad. i am all for deprecating the old one and dropping it
at a later release. but for that we probably need some additional work
in  other oak components that currently rely on the accessibility and
public nature of the security provider implementation (e.g. in oak-jcr).
i don't think we need it as a private class, we just have to refactor
oak to use the new setup (which might take some more effort) and
then remove the old at a later stage.

kind regards and thanks again for your effort
angela

On 21/09/15 16:34, "Francesco Mari"  wrote:

>Some updates on this topic.
>
>2015-09-18 17:27 GMT+02:00 Francesco Mari :
>> Hi Angela,
>>
>> 2015-09-18 16:48 GMT+02:00 Angela Schreiber :
>>> hi francesco
>>>
>>> thanks a lot for taking care of this issue! very much appreciated.
>>>
>>> just a few comments:
>>> as just discussed in private required configurationin
>>> RandomAuthorizableNodeName
>>> is mandatory. please don't remove it... just because CQ has this
>>> configured by default doesn't mean that it's the default in oak
>>> (it isn't for backwards compatibility as you can see in the
>>> documentation).
>>>
>>
>> I opened OAK-3423 and assigned it to me to be sure not to forget to
>> revert this change.
>>
>
>The issue has been resolved. RandomAuthorizableNodeName is not part of
>the default preconditions of SecurityProvider anymore.
>
>>> second, i feel a bit uneasy about the compability break in
>>> SecurityProviderImpl
>>> which is a public class and exported... let's discuss that again
>>> next week.
>>>
>>
>
>I have a solution that would revert the changes made to
>SecurityProviderImpl. The solution, proposed for review in OAK-3434,
>is to expose two implementations of SecurityProvider. The first is
>SecurityProviderImpl, the second is the one registered by
>SecurityProviderRegistration. The second implementation is registered
>with a property "type" having a value of "default".  The
>RepositoryManager now uses the SecurityProvider implementation
>exposing this registration property. The two implementations should be
>able to coexist, even if I'm worried of OAK-3392.
>
>> I have mixed feelings about the backwards compatibility of
>> SecurityProviderImpl. On one side, it would be really bad to have
>> clients extending this class for their own purposes and missing the
>> activate/deactivate/bind/unbind methods. On the other side, the fact
>> that this component changed its own nature, from an OSGi component to
>> a plain Java object, seems a breaking change that is important enough
>> to justify a breakage of its API, too. In any case, I think that this
>> topic deserves some additional thought. As you said, let's discuss
>> about it next week.
>>
>
>After taking a closer look at the problem, I arrived to the conclusion
>that the visibility of SecurityProviderImpl was wrong in the first
>place. It is considered bad practice to include a component/service
>implementation in an exported package. This exposes the implementation
>of the bundle to its clients, and from the OSGi perspective it is as
>bad as declaring a field public.
>
>There is at least another component implementation I met that is
>exposed by an exported package: DefaultAuthorizableActionProvider.
>This is both a component and part of the SPI of the security
>subsystem. As such, it is in the same situation as
>SecurityProviderImpl. The evolvability of
>DefaultAuthorizableActionProvider as a component is restricted by it
>being part of an exported package.
>
>Should we think about deprecating SecurityProviderImpl and
>DefaultAuthorizableActionProvider and move these implementations into
>a private package?
>
>>> and finally... the SecurityProviderRegistration should have annotations
>>> for the public methods that are nowhere used inside oak
>>>(SuppressWarning).
>>> can you add those?
>>>
>>
>> I will. I didn't open an issue for the @SuppressWarnings because it
>> will be a small, trivial change that will be done on the fly.
>>
>
>This has been done in one of my commits today.
>
>>> thanks a lot and have a nice weekend
>>
>> You too!
>>
>>> angela

Re: Run maven-bundle-plugin:baseline when skipTests=true

[Angela Schreiber]

hi francesco

i only skip the tests if i am trying something out quickly but
never if i am testing something that i plan to commit/push.

so, IMO the skipTests is really just for getting an untested,
incomplete, versioning-violating temporary build, when i need
something quickly. e.g. i am running some benchmarks and need
to recompile oak-core with a minor change during development
and don't want to wait a quarter of an hour.

therefore i would rather not change the skipTests and keep
it as fast as possible.

kind regards
angela

On 29/09/15 10:44, "Francesco Mari"  wrote:

>Hi all,
>
>The current build configuration skips the execution of the baseline
>goal from the maven-bundle-plugin when the skipTests property is true.
>
>I would like to run the baseline goal even when skipTests is true,
>instead. Even if the executions of tests is skipped, the plugin still
>gives useful information about potential versioning violations in
>exported packages. These checks are independent from and complementary
>to tests, so I don't see any reason to skip these checks when the
>tests are skipped.
>
>What do you think?

Re: jackrabbit-oak build #6641: Broken

[Angela Schreiber]

the failing test is

  
nodeWithMediumBlob[1](org.apache.jackrabbit.oak.plugins.segment.RecordUsage
AnalyserTest): Java heap space


i don't see how this is related to my changes. any pointer?

kind regards
angela

On 15/10/15 12:55, "Travis CI"  wrote:

>Build Update for apache/jackrabbit-oak
>-
>
>Build: #6641
>Status: Broken
>
>Duration: 412 seconds
>Commit: 24f7f60a2ef605dbc176049300d8ead41974d24b (trunk)
>Author: Angela Schreiber
>Message: OAK-3517 : Node.addNode(String, String) may check permissions
>against the wrong node
>
>git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1708766
>13f79535-47bb-0310-9956-ffa450edef68
>
>View the changeset:
>https://github.com/apache/jackrabbit-oak/compare/0c4317097925...24f7f60a2e
>f6
>
>View the full build log and details:
>https://travis-ci.org/apache/jackrabbit-oak/builds/85504933
>
>--
>sent by Jukka's Travis notification gateway

Re: jackrabbit-oak build #6643: Broken

[Angela Schreiber]

the failing test is


Failed tests:   
testGetSize(org.apache.jackrabbit.core.query.QueryResultTest): Wrong size
of NodeIterator in result expected:<54> but was:<-1>


i don't think that's related to the modifications made,
which address a bug during execution of Node.addNode
in oak-jcr

regards
angela

On 15/10/15 15:29, "Travis CI"  wrote:

>Build Update for apache/jackrabbit-oak
>-
>
>Build: #6643
>Status: Broken
>
>Duration: 2385 seconds
>Commit: f7e4c2e6154750400c01ee13dd4bb6a622c5ed0b (1.2)
>Author: Angela Schreiber
>Message: merging rev. 1708766 (OAK-3517)
>
>git-svn-id: 
>https://svn.apache.org/repos/asf/jackrabbit/oak/branches/1.2@1708811
>13f79535-47bb-0310-9956-ffa450edef68
>
>View the changeset:
>https://github.com/apache/jackrabbit-oak/compare/2badc93bf394...f7e4c2e615
>47
>
>View the full build log and details:
>https://travis-ci.org/apache/jackrabbit-oak/builds/85522034
>
>--
>sent by Jukka's Travis notification gateway

Re: Implementation classes in o.a.j.o.spi package

[Angela Schreiber]

hi francesco

wouldn't it be easier to start with o.a.j.o.api package first?
also that package has been very stable over the last months
and would IMO be a better candidate than the spi.

also the spi contains so many different things that most
probably should rather be split (i.e. security from the
state and commit stuff). fwiw we already have other
modules that cover the spi package space.

kind regards
angela

On 22/10/15 16:01, "Francesco Mari"  wrote:

>Hi,
>
>I recently started looking into the o.a.j.o.spi package to figure out
>if it would be possible to decouple it from oak-core, but I found out
>that many implementation classes live there.
>
>In particular, almost every subpackage contains default
>implementations of proper SPI interfaces, like CompositeEditor,
>CompositeHook, EmptyHook, etc. These classes should probably be part
>of a utility package instead.
>
>These default implementations make o.a.j.o.spi (and its subpackages)
>transitively depend on many other implementation packages, while I
>expect an SPI package to depend only on other SPI and API packages.
>
>What about moving the implementation classes into different utility
>packages?

Re: svn commit: r1710162 - in /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak: api/PropertyState.java api/Tree.java api/Type.java api/package-info.java plugins/memory/ModifiedNo

[Angela Schreiber]

hi francesco

i disagree with your statement below. having tests even for trivial
changes just limits the risk of regressions now and for any later
modifications... hoping for others having covered your code with
some test, is IMO not good enough :-)

so, please add some tests or verify that it's actually covered
by some others (intelliJ actually allows you to visualise that
pretty easily when running tests with colllecting test-coverage).

kind regards
angela 

On 23/10/15 12:13, "Francesco Mari"  wrote:

>I don't think that in this case a test is necessary, given the
>triviality of the change. Type is used by almost the whole stack, and
>the fixes are about the comparison between types. If I introduced a
>regression, it should have been caught by at least one test
>(hopefully).
>
>2015-10-23 12:08 GMT+02:00 Chetan Mehrotra :
>> On Fri, Oct 23, 2015 at 3:15 PM,   wrote:
>>> public final class Type implements Comparable> {
>>>
>>> -private static final Map> TYPES = newHashMap();
>>> +private static final Map> TYPES = new
>>>HashMap>();
>>>
>>>  private static  Type create(int tag, boolean array, String
>>>string) {
>>>  Type type = new Type(tag, array, string);
>>> @@ -242,10 +237,23 @@ public final class Type implements Co
>>>
>>>  @Override
>>>  public int compareTo(@Nonnull Type that) {
>>> -return ComparisonChain.start()
>>> -.compare(tag, that.tag)
>>> -.compareFalseFirst(array, that.array)
>>> -.result();
>>> +if (tag < that.tag) {
>>> +return -1;
>>> +}
>>> +
>>> +if (tag > that.tag) {
>>> +return 1;
>>> +}
>>> +
>>> +if (!array && that.array) {
>>> +return -1;
>>> +}
>>> +
>>> +if (array && !that.array) {
>>> +return 1;
>>> +}
>>> +
>>> +return 0;
>>>  }
>>
>> I am fine with removing dependency on Guava from API but not sure if
>> we should remove it from implementation side
>>
>> Also it would be good to have a testcase to validate the above logic
>> if we are removing dependency from a tested Guava utility method
>>
>> Chetan Mehrotra

Re: trunk build failing

[Angela Schreiber]

hi alex

that might be related to OAK-3541. i committed an initial fix because
the issue completely blocked me... though OAK-3541 is rather located
in the version storage it might now reveal other bugs we didn't spot
up to now.

can you create another issue and link it to OAK-3541?
i planned to write more tests for the other OPV flags to verify if my
patch really does the right thing. if it turns out that a different fix
is needed for OAK-3541, i can try fixing the OPV... however if properly
fixing OAK-3541 would reveal more (and substancial) issues with the
version 
implementation hidden up to now, i think marcel would need to take over as
the original author of the versioning in Oak.

hope that helps
angela


On 26/10/15 11:58, "Alex Parvulescu"  wrote:

>... and a sample of a failing test:
>
>testRestoreChild1(org.apache.jackrabbit.test.api.version.RestoreTest)
>Time
>elapsed: 0.019 sec  <<< ERROR!
>javax.jcr.RepositoryException:
>org.apache.jackrabbit.oak.api.CommitFailedException: OakConstraint0022:
>/testroot/versionableNodeName1/child1[[test:versionable]]: Mandatory
>property jcr:versionHistory can not be removed
>at
>org.apache.jackrabbit.oak.jcr.version.VersionManagerImpl$2.performVoid(Ver
>sionManagerImpl.java:204)
>at
>org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(Session
>Delegate.java:273)
>at
>org.apache.jackrabbit.oak.jcr.version.VersionManagerImpl.restore(VersionMa
>nagerImpl.java:168)
>at
>org.apache.jackrabbit.oak.jcr.version.VersionManagerImpl.restore(VersionMa
>nagerImpl.java:149)
>at
>org.apache.jackrabbit.oak.jcr.session.NodeImpl.restore(NodeImpl.java:1162)
>at
>org.apache.jackrabbit.test.api.version.RestoreTest.testRestoreChild1(Resto
>reTest.java:804)
>
>
>On Mon, Oct 26, 2015 at 11:58 AM, Alex Parvulescu
>> wrote:
>
>> Hi,
>>
>> the trunk IT build is failing, could someone please take a look?
>>
>> Tests in error:
>>
>>   testRestoreChild1(org.apache.jackrabbit.test.api.version.RestoreTest):
>> org.apache.jackrabbit.oak.api.CommitFailedException: OakConstraint0022:
>> /testroot/versionableNodeName1/child1[[test:versionable]]: Mandatory
>> property jcr:versionHistory can not be removed
>>
>>
>> 
>>testRestoreChild1Jcr2_2(org.apache.jackrabbit.test.api.version.RestoreTes
>>t):
>> org.apache.jackrabbit.oak.api.CommitFailedException: OakConstraint0022:
>> /testroot/versionableNodeName1/child1[[test:versionable]]: Mandatory
>> property jcr:versionHistory can not be removed
>>
>>
>> 
>>testRestoreChild1Jcr2_3(org.apache.jackrabbit.test.api.version.RestoreTes
>>t):
>> org.apache.jackrabbit.oak.api.CommitFailedException: OakConstraint0022:
>> /testroot/versionableNodeName1/child1[[test:versionable]]: Mandatory
>> property jcr:versionHistory can not be removed
>>
>>
>> 
>>testRestoreChild1Jcr2_4(org.apache.jackrabbit.test.api.version.RestoreTes
>>t):
>> org.apache.jackrabbit.oak.api.CommitFailedException: OakConstraint0022:
>> /testroot/versionableNodeName1/child1[[test:versionable]]: Mandatory
>> property jcr:versionHistory can not be removed
>>
>>
>> 
>>testRestoreChild1Jcr2(org.apache.jackrabbit.test.api.version.RestoreTest)
>>:
>> org.apache.jackrabbit.oak.api.CommitFailedException: OakConstraint0022:
>> /testroot/versionableNodeName1/child1[[test:versionable]]: Mandatory
>> property jcr:versionHistory can not be removed
>>

Re: svn commit: r1712931 - in /jackrabbit/oak/trunk: oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/ oak-commons/src/test/java/org/apache/jackrabbit/oak/commons/ oak-core/src/main/java/or

[Angela Schreiber]

hi michael

but it's an internal method in an internal class and i don't see
how an API consumer can overwrite it... that's why the check really
looks redundant to me in particular as it would equally result in an NPE,
which looks bad anyway.

kind regards
angela

On 06/11/15 11:31, "Michael Dürig"  wrote:

>
>Hi,
>
>On 6.11.15 10:03 , ang...@apache.org wrote:
>> Author: angela
>> Date: Fri Nov  6 10:03:03 2015
>> New Revision: 1712931
>>
>> URL: http://svn.apache.org/viewvc?rev=1712931&view=rev
>> Log:
>> OAK-3593 : improvements to plugins/tree
>>
>
>
>> Modified: 
>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plu
>>gins/tree/impl/AbstractTree.java
>> URL: 
>>http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/main/java/
>>org/apache/jackrabbit/oak/plugins/tree/impl/AbstractTree.java?rev=1712931
>>&r1=1712930&r2=1712931&view=diff
>> 
>>=
>>=
>> --- 
>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plu
>>gins/tree/impl/AbstractTree.java (original)
>> +++ 
>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plu
>>gins/tree/impl/AbstractTree.java Fri Nov  6 10:03:03 2015
>> @@ -18,7 +18,6 @@
>
>>   protected void buildPath(@Nonnull StringBuilder sb) {
>>   AbstractTree parent = getParentOrNull();
>>   if (parent != null) {
>> -parent.buildPath(checkNotNull(sb));
>> +parent.buildPath(sb);
>>   sb.append('/').append(getName());
>>   }
>
>I don't think those null check are redundant here and I would like to
>have them back. The @Nonnull annotation does some rather week static
>analysis, which is helpful but by no means complete. The missing null
>check easily makes a API usage error look like an implementation error
>thus causing bogus bug reports.
>
>Michael

Re: svn commit: r1712931 - in /jackrabbit/oak/trunk: oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/ oak-commons/src/test/java/org/apache/jackrabbit/oak/commons/ oak-core/src/main/java/or

[Angela Schreiber]

hi michael

as for the other calls: i would suggest that we only
have the checks in the MutableTree and not in the AbstractTree
which serves as base both for the internally used
ImmutableTree and the public MutableTree.

probably that's a leftover of the refactoring that resulted
in the AbstractTree as for some methods that checks are in
MutableTree already. so, i can instead move the checkForNull
calls there, if you agree.

kind regards
angela

On 06/11/15 11:40, "Angela Schreiber"  wrote:

>hi michael
>
>but it's an internal method in an internal class and i don't see
>how an API consumer can overwrite it... that's why the check really
>looks redundant to me in particular as it would equally result in an NPE,
>which looks bad anyway.
>
>kind regards
>angela
>
>On 06/11/15 11:31, "Michael Dürig"  wrote:
>
>>
>>Hi,
>>
>>On 6.11.15 10:03 , ang...@apache.org wrote:
>>> Author: angela
>>> Date: Fri Nov  6 10:03:03 2015
>>> New Revision: 1712931
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1712931&view=rev
>>> Log:
>>> OAK-3593 : improvements to plugins/tree
>>>
>>
>>
>>> Modified: 
>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/pl
>>>u
>>>gins/tree/impl/AbstractTree.java
>>> URL: 
>>>http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/main/java
>>>/
>>>org/apache/jackrabbit/oak/plugins/tree/impl/AbstractTree.java?rev=171293
>>>1
>>>&r1=1712930&r2=1712931&view=diff
>>> 
>>>
>>>=
>>>=
>>> --- 
>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/pl
>>>u
>>>gins/tree/impl/AbstractTree.java (original)
>>> +++ 
>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/pl
>>>u
>>>gins/tree/impl/AbstractTree.java Fri Nov  6 10:03:03 2015
>>> @@ -18,7 +18,6 @@
>>
>>>   protected void buildPath(@Nonnull StringBuilder sb) {
>>>   AbstractTree parent = getParentOrNull();
>>>   if (parent != null) {
>>> -parent.buildPath(checkNotNull(sb));
>>> +parent.buildPath(sb);
>>>   sb.append('/').append(getName());
>>>   }
>>
>>I don't think those null check are redundant here and I would like to
>>have them back. The @Nonnull annotation does some rather week static
>>analysis, which is helpful but by no means complete. The missing null
>>check easily makes a API usage error look like an implementation error
>>thus causing bogus bug reports.
>>
>>Michael
>

Re: svn commit: r1712931 - in /jackrabbit/oak/trunk: oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/ oak-commons/src/test/java/org/apache/jackrabbit/oak/commons/ oak-core/src/main/java/or

[Angela Schreiber]

done
kind regards
angela

On 06/11/15 12:14, "Michael Dürig"  wrote:

>
>Hi Angela,
>
>That's right. Probably a leftover from when we factored out
>AbstractTree. We should probably move the null checks up to the public
>facing tree implementations.
>
>Michael
>
>On 6.11.15 10:40 , Angela Schreiber wrote:
>> hi michael
>>
>> but it's an internal method in an internal class and i don't see
>> how an API consumer can overwrite it... that's why the check really
>> looks redundant to me in particular as it would equally result in an
>>NPE,
>> which looks bad anyway.
>>
>> kind regards
>> angela
>>
>> On 06/11/15 11:31, "Michael Dürig"  wrote:
>>
>>>
>>> Hi,
>>>
>>> On 6.11.15 10:03 , ang...@apache.org wrote:
>>>> Author: angela
>>>> Date: Fri Nov  6 10:03:03 2015
>>>> New Revision: 1712931
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1712931&view=rev
>>>> Log:
>>>> OAK-3593 : improvements to plugins/tree
>>>>
>>>
>>>
>>>> Modified:
>>>> 
>>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/p
>>>>lu
>>>> gins/tree/impl/AbstractTree.java
>>>> URL:
>>>> 
>>>>http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/main/jav
>>>>a/
>>>> 
>>>>org/apache/jackrabbit/oak/plugins/tree/impl/AbstractTree.java?rev=17129
>>>>31
>>>> &r1=1712930&r2=1712931&view=diff
>>>>
>>>> 
>>>>===
>>>>==
>>>> =
>>>> ---
>>>> 
>>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/p
>>>>lu
>>>> gins/tree/impl/AbstractTree.java (original)
>>>> +++
>>>> 
>>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/p
>>>>lu
>>>> gins/tree/impl/AbstractTree.java Fri Nov  6 10:03:03 2015
>>>> @@ -18,7 +18,6 @@
>>>
>>>>protected void buildPath(@Nonnull StringBuilder sb) {
>>>>AbstractTree parent = getParentOrNull();
>>>>if (parent != null) {
>>>> -parent.buildPath(checkNotNull(sb));
>>>> +parent.buildPath(sb);
>>>>sb.append('/').append(getName());
>>>>}
>>>
>>> I don't think those null check are redundant here and I would like to
>>> have them back. The @Nonnull annotation does some rather week static
>>> analysis, which is helpful but by no means complete. The missing null
>>> check easily makes a API usage error look like an implementation error
>>> thus causing bogus bug reports.
>>>
>>> Michael
>>

document.persistentCache.BroadcastTest failing

[Angela Schreiber]

hi 

there are 2 tests failing with my checkout, which don't seem to
be related to may pending changes (which i just wanted to test
again):

Tests run: 3, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 4.498 sec
<<< FAILURE!
broadcastEncryptedUDP(org.apache.jackrabbit.oak.plugins.document.persistent
Cache.BroadcastTest)  Time elapsed: 2.208 sec  <<< FAILURE!
java.lang.AssertionError: min: 50 got: 0
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.br
oadcast(BroadcastTest.java:78)
at 
org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.br
oadcastEncryptedUDP(BroadcastTest.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3
9)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
l.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod
.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.
java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.j
ava:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.ja
va:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.ja
va:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.ja
va:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java
:252)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provid
er.java:141)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:
112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3
9)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
l.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(Reflec
tionUtils.java:189)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(Provi
derFactory.java:165)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFac
tory.java:85)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBoot
er.java:115)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

broadcastUDP(org.apache.jackrabbit.oak.plugins.document.persistentCache.Bro
adcastTest)  Time elapsed: 2.137 sec  <<< FAILURE!
java.lang.AssertionError: min: 50 got: 0
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.br
oadcast(BroadcastTest.java:78)
at 
org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.br
oadcastUDP(BroadcastTest.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3
9)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
l.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod
.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.
java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.j
ava:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.ja
va:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.ja
va:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.ja
va:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
  

NPE in org.apache.jackrabbit.oak.jcr.query.QueryFulltextTest

[Angela Schreiber]

hi davide

thanks for fixing the baseline issues (OAK-3628). however, i getting the
following failure now. would it be possible to revert those latest
changes for query-fulltext that seem to be responsible for both?
or is there anything i can do other than ignoring the test?

kind regards
angela

Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.195 sec
<<< FAILURE!
excerpt[SegmentStore](org.apache.jackrabbit.oak.jcr.query.QueryFulltextTest
)  Time elapsed: 0.101 sec  <<< ERROR!
java.lang.NullPointerException
at 
org.apache.jackrabbit.oak.query.fulltext.SimpleExcerptProvider.getExcerpt(S
impleExcerptProvider.java:260)
at 
org.apache.jackrabbit.oak.query.ResultRowImpl.getValue(ResultRowImpl.java:1
15)
at org.apache.jackrabbit.oak.jcr.query.RowImpl.getValue(RowImpl.java:96)
at 
org.apache.jackrabbit.oak.jcr.query.QueryFulltextTest.excerpt(QueryFulltext
Test.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3
9)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
l.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod
.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.
java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.j
ava:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.ja
va:17)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.ja
va:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.ja
va:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.j
ava:895)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:
918)
at java.lang.Thread.run(Thread.java:695)

Re: New to Oak, help with webdav

[Angela Schreiber]

hi david

are you looking for real webdav support or for the jcr
remoting which is partially done with webdav request methods?

kind regards
angela

On 17/11/15 01:46, "David Marginian"  wrote:

>I am new to both JackRabbit and Oak and trying to upgrade an existing
>system to use Oak.  I want to access the repo via webdav and currently I
>obtain the repo by passing the URL into JcrUtils.getRepository.  I am
>struggling to figure out how to do the same thing in Oak.  I am running
>the Oak server via the jar:
>
>java -jar oak-run-1.2.7.jar server http://localhost:8452 Oak-Mongo --db
>myOak --host localhost --port 8524
>
>this creates the myOak DB in Mongo and I can hit
>http://localhost:8452/webdav/default via the browser.  But when I try to
>use JcrUtils.getRepository from my code I get:
>
>Caused by: javax.jcr.RepositoryException: Unable to access a repository
>with the following settings:
> org.apache.jackrabbit.repository.uri:
>http://localhost:8452/webdav/default
>The following RepositoryFactory classes were consulted:
> org.apache.jackrabbit.jcr2dav.Jcr2davRepositoryFactory: declined
> org.apache.jackrabbit.jcr2spi.Jcr2spiRepositoryFactory: declined
> org.apache.jackrabbit.oak.jcr.OakRepositoryFactory: declined
> org.apache.jackrabbit.commons.JndiRepositoryFactory: declined
>
>I realize I am using the old JackRabbit API but I am not sure how to do
>this via Oak.  I am sure I am missing something basic, can someone help
>me out, point me in the right direction?
>
>Thanks for your time

Re: New to Oak, help with webdav

[Angela Schreiber]

hi david

hm but the link below (http://localhost:8452/webdav/default)
rather looks like default webdav.

as a general note i don't see any compelling reason why both
webdav and jcr-remoting should not work when replacing jackrabbit-core
repository by oak. the only thing that you probably have to do
is running the migration first.

looking at the code in oak-run that setups up the server it find
the following:

final Repository jcrRepository = jcr.createRepository();
@SuppressWarnings("serial")
ServletHolder webdav = new ServletHolder(new SimpleWebdavServlet() {
@Override
public Repository getRepository() {
return jcrRepository;
}
});
webdav.setInitParameter(SimpleWebdavServlet.INIT_PARAM_RESOURCE_PATH_PREFIX
, path + "/webdav");
webdav.setInitParameter(AbstractWebdavServlet.INIT_PARAM_AUTHENTICATE_HEADE
R, "Basic realm=\"Oak\"");
context.addServlet(webdav, path + "/webdav/*");


// 3 - JCR Remoting Server
@SuppressWarnings("serial")
ServletHolder jcrremote = new ServletHolder(new JcrRemotingServlet() {
@Override
protected Repository getRepository() {
return jcrRepository;
}
});
jcrremote.setInitParameter(JCRWebdavServerServlet.INIT_PARAM_RESOURCE_PATH_
PREFIX, path + "/jcrremote");
jcrremote.setInitParameter(AbstractWebdavServlet.INIT_PARAM_AUTHENTICATE_HE
ADER, "Basic realm=\"Oak\"");
context.addServlet(jcrremote, path + "/jcrremote/*");



i am not the author of this code and never tried it out.
it might well be, that something is missing could you
try to set it up manually?

alternatively you can report a jira issue with reproducible
steps on what you do, what the expected outcome is and
what doesn't work.

kind regards
angela



On 17/11/15 09:40, "David Marginian"  wrote:

>Hi Angela,
>Jcr remoting should be fine as I believe that is what I am using now
>with the older version of JackRabbit.
>
>On 11/17/2015 12:45 AM, Angela Schreiber wrote:
>> hi david
>>
>> are you looking for real webdav support or for the jcr
>> remoting which is partially done with webdav request methods?
>>
>> kind regards
>> angela
>>
>> On 17/11/15 01:46, "David Marginian"  wrote:
>>
>>> I am new to both JackRabbit and Oak and trying to upgrade an existing
>>> system to use Oak.  I want to access the repo via webdav and currently
>>>I
>>> obtain the repo by passing the URL into JcrUtils.getRepository.  I am
>>> struggling to figure out how to do the same thing in Oak.  I am running
>>> the Oak server via the jar:
>>>
>>> java -jar oak-run-1.2.7.jar server http://localhost:8452 Oak-Mongo --db
>>> myOak --host localhost --port 8524
>>>
>>> this creates the myOak DB in Mongo and I can hit
>>> http://localhost:8452/webdav/default via the browser.  But when I try
>>>to
>>> use JcrUtils.getRepository from my code I get:
>>>
>>> Caused by: javax.jcr.RepositoryException: Unable to access a repository
>>> with the following settings:
>>>  org.apache.jackrabbit.repository.uri:
>>> http://localhost:8452/webdav/default
>>> The following RepositoryFactory classes were consulted:
>>>  org.apache.jackrabbit.jcr2dav.Jcr2davRepositoryFactory: declined
>>>  org.apache.jackrabbit.jcr2spi.Jcr2spiRepositoryFactory: declined
>>>  org.apache.jackrabbit.oak.jcr.OakRepositoryFactory: declined
>>>  org.apache.jackrabbit.commons.JndiRepositoryFactory: declined
>>>
>>> I realize I am using the old JackRabbit API but I am not sure how to do
>>> this via Oak.  I am sure I am missing something basic, can someone help
>>> me out, point me in the right direction?
>>>
>>> Thanks for your time
>>
>

Re: [jira] [Updated] (OAK-3632) Incorrect Value Conversion upon Node.setProperty and Node.setValue

[Angela Schreiber]

hi marcel

thanks for fixing the version.

wouldn't it make sense to remove the a given fix-version
from the selection as soon as we _start_ the release process?

that versions is anyway taken and won't be re-used even if
the release vote doesn't pass. removing it at the start
would prevent wrong fix versions for issues that get
fixed while the vote is open.

wdyt?
angela


On 24/11/15 09:08, "Marcel Reutegger (JIRA)"  wrote:

>
> [ 
>https://issues.apache.org/jira/browse/OAK-3632?page=com.atlassian.jira.plu
>gin.system.issuetabpanels:all-tabpanel ]
>
>Marcel Reutegger updated OAK-3632:
>--
>Fix Version/s: (was: 1.3.11)
>   1.3.12
>
>> Incorrect Value Conversion upon Node.setProperty and Node.setValue
>> --
>>
>> Key: OAK-3632
>> URL: https://issues.apache.org/jira/browse/OAK-3632
>> Project: Jackrabbit Oak
>>  Issue Type: Technical task
>>  Components: jcr
>>Reporter: angela
>> Fix For: 1.3.12
>>
>> Attachments: OAK-3632.patch
>>
>>
>> see container issue for test-cases and description
>
>
>
>--
>This message was sent by Atlassian JIRA
>(v6.3.4#6332)

Re: jackrabbit-oak build #7043: Errored

[Angela Schreiber]

the failure as far as i can see is:

  Running org.apache.jackrabbit.oak.jcr.AsyncConflictsIT

  No output has been received in the last 10 minutes, this potentially
indicates a stalled build or something wrong with the build itself.
  The build has been terminated

i don't think this is related to the changes made.
kind regards
angela



On 09/12/15 17:58, "Travis CI"  wrote:

>Build Update for apache/jackrabbit-oak
>-
>
>Build: #7043
>Status: Errored
>
>Duration: 2173 seconds
>Commit: 88dccebec307c629e01980181745a67fe8b69813 (trunk)
>Author: Angela Schreiber
>Message: OAK-3759 : UserManager.onCreate is not omitted for system users
>in case of XML import
>
>git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1718873
>13f79535-47bb-0310-9956-ffa450edef68
>
>View the changeset:
>https://github.com/apache/jackrabbit-oak/compare/99579567bf7b...88dccebec3
>07
>
>View the full build log and details:
>https://travis-ci.org/apache/jackrabbit-oak/builds/95828009
>
>--
>sent by Jukka's Travis notification gateway

Re: jackrabbit-oak build #7081: Errored

[Angela Schreiber]

the error:

Running org.apache.jackrabbit.oak.jcr.query.QueryJcrTestIT
No output has been received in the last 10 minutes, this potentially
indicates a stalled build or something wrong with the build itself.

no sure how that would be related to my changes.
br
angela

On 17/12/15 19:30, "Travis CI"  wrote:

>Build Update for apache/jackrabbit-oak
>-
>
>Build: #7081
>Status: Errored
>
>Duration: 2564 seconds
>Commit: e261b416fdf34635faaf2e3109641716bacc2751 (trunk)
>Author: Angela Schreiber
>Message: OAK-3704 : Keep track of nested CUGs (WIP)
>
>git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1720618
>13f79535-47bb-0310-9956-ffa450edef68
>
>View the changeset:
>https://github.com/apache/jackrabbit-oak/compare/8e3ebf4088bf...e261b416fd
>f3
>
>View the full build log and details:
>https://travis-ci.org/apache/jackrabbit-oak/builds/97501383
>
>--
>sent by Jukka's Travis notification gateway

Failing SegmentToJdbcTest.validateMigration

[Angela Schreiber]

hi oak devs

i keep getting test failure with SegmentToJdbcTest.validateMigration
every now and then but can't reliably reproduce it when debugging
the test (as thomas can confirm ;-)).

stepping into the AbstractOak2OakTest and finally
RepositorySidegrade.copyState i actually see that the target NodeBuilder
that results from copyWorkspace doesn't have the jcr:mixinTypes
property copied from the src to the target, which consequently
(and rightfully) results in the first Root.commit to fail, because
the rep:policy node present in the test-content is considered
isolated (i.e. the /-tree doesn't have the mix:AccessControllable
mixin type set, which is pretty obvious if jcr:mixinTypes property
is not copied over).

who is familiar with RepositorySidegrade and could take a closer
look what is going wrong here? i run into this when testing the changes
attached to OAK-4119 but i fail to see how those changes should impact
the copy performed by RepositorySidegrade.

kind regards
angela

PS: i also found https://issues.apache.org/jira/browse/OAK-2714
mentioning the exact same test to fail on Jenkins.

Re: Failing SegmentToJdbcTest.validateMigration

[Angela Schreiber]

Hi Tomek

Thanks a lot for the confirmation and the issue!

Just as a side node: our Adobe internal repositories
_always_ have a policy node at the root. If the sidegrade
is likely to be used in real, productive environments
this should IMO be considered a critical bug.

Thanks and kind regards
Angela


On 16/03/16 14:00, "Tomek Rekawek"  wrote:

>Hello Angela,
>
>> On 16 Mar 2016, at 12:39, Angela Schreiber  wrote:
>> 
>> stepping into the AbstractOak2OakTest and finally
>> RepositorySidegrade.copyState i actually see that the target NodeBuilder
>> that results from copyWorkspace doesn't have the jcr:mixinTypes
>> property copied from the src to the target, which consequently
>
>Indeed, it seems there's a bug, which causes the RepositorySidegrade to
>skip the root node properties. I think the reason lies in the
>calculateEffectiveIncludePaths() method, which produces an effective list
>of paths to migrate. If we have a '/' in the input list, the method will
>replace it with a list of '/' children and the root itself is removed
>from the list.
>
>Similar issue is present in the RepositoryUpgrade, but it isn't so
>dangerous there, as we create the root node anyway using an initializer.
>
>Created OAK-4128 to track this.
>
>However, the OAK-4128 is reproducible and present not only on the JDBC
>destination, so I guess the random failures (including the ones on
>Jenkins) are related to something else.
>
>Best regards,
>Tomek
>
>-- 
>Tomek Rękawek | Adobe Research | www.adobe.com
>reka...@adobe.com
>

Re: Problems with OAK restrictions

[Angela Schreiber]

hi gianluca

the glob pattern doesn't distinguish between nodes and properties and
just verifies if the path of a given item matches the specified pattern.
so, having the pattern value set to empty string limits the effect of the
ace to that very node. the properties of that node are not accessible.
so, the outcome is expected.

i guess OAK-2437 
(https://issues.apache.org/jira/browse/OAK-2437) would
be the what you are looking for.

until this is resolved you can work around by adding an additional entry that
grants rep:readProperties privilege to you principal just for the 
'jcr:primaryType'
property.

hope that helps
angela

From: 
"gianluca.soffred...@metaframe.it" 
mailto:gianluca.soffred...@metaframe.it>>
Reply-To: "oak-dev@jackrabbit.apache.org" 
mailto:oak-dev@jackrabbit.apache.org>>
Date: Wednesday 30 March 2016 18:54
To: "oak-dev@jackrabbit.apache.org" 
mailto:oak-dev@jackrabbit.apache.org>>
Subject: Problems with OAK restrictions

Good evening,

I still write for the problem I found in the management of the rep:glob 
restriction  set to empty string.
I made more tests and I also used the ReadTest class of OAK.

In effect the restriction rep:glob set to empty string works on nodes.
If I apply the restriction on path /my_folder by adding the permission of READ, 
both with the call to Session.getNode ("/ my_folder") that with the call to
Session.getRootNode (). getNodes () the system can access to the path.

The problem is when I run the query "select F. * from [nt: folder] as F". The 
query result is empty.
It seems to me weird because if I access to the node I should also have access 
to the folder that the node represents.

Analyzing the OAK code in version 1.4.0 I have found the GlobPattern class.
In the case of restriction rep:glob set to empty string that class always uses 
the PathPattern class and always makes the call path.equals(toMatch).
This call works when the path /my_folder is used in nodes and it works
even when the path is evaluated in the query "select * from F. [nt: folder] as 
F".
The problem is the following: during query execution is also rightly evaluated
the jcr: primaryType node. In this case, the primary type is nt: folder.
It is called again the following method of GlobPattern class:

@Override
public boolean matches(@Nonnull Tree tree, @Nullable PropertyState 
property) {
String itemPath = (property == null) ? tree.getPath() : 
PathUtils.concat(tree.getPath(), property.getName());
return matches(itemPath);
}

and then the matches method of the class PathPattern:

   @Override
boolean matches(@Nonnull String toMatch) {
if (patternStr.isEmpty()) {
return path.equals(toMatch);
} else {
// no wildcard contained in restriction: use path defined
// by path + restriction to calculate the match
return Text.isDescendantOrEqual(patternStr, toMatch);
}
}

This call can not works because in the case in which patternStr.isEmpty() is 
called the method path.equals(toMatch).

But the path class attribute is set to  /my_folder and the toMatch variable is 
set to /my_folder/jrc: primaryType. It 's clear that the call to the equals 
method will return false.

To solve the problem I changed the class OAK GlobPattern as follows, and now 
the query "select * from F. [nt: folder] as F" correctly returns in its results 
the folder /my_folder.

/*
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package org.apache.jackrabbit.oak.security.authorization.restriction;

import static com.google.common.base.Preconditions.checkNotNull;

import javax.annotation.Nonnull;
import javax.annotation.Nullable;
import javax.jcr.security.AccessControlException;

import org.apache.jackrabbit.oak.api.PropertyState;
import org.apache.jackrabbit.oak.api.Tree;
import org.apache.jackrabbit.oak.commons.PathUtils;
import 
org.apache.jackrabbit.oak.spi.security.authorization.restriction.RestrictionPattern;
import org.apache.jackrabbit.util.Text;

import com.google.common.base.

Re: Failing SegmentToJdbcTest.validateMigration

[Angela Schreiber]

Hi Tomek

While I see that OAK-4128 has been resolved fixed, I still experience
a failing SegmentToJdbcTest.validateMigration test, with my pending
changes for OAK-4119.

I will take the liberty to mark the test with an @Ignore tag when
committing my changes. What's your preferred way to investigate
this? Shall I clone the OAK-4119? Or do you want to take a closer
look once I am done such that you can actually experience the
failure?

Kind regards
Angela

On 16/03/16 14:26, "Angela Schreiber"  wrote:

>Hi Tomek
>
>Thanks a lot for the confirmation and the issue!
>
>Just as a side node: our Adobe internal repositories
>_always_ have a policy node at the root. If the sidegrade
>is likely to be used in real, productive environments
>this should IMO be considered a critical bug.
>
>Thanks and kind regards
>Angela
>
>
>On 16/03/16 14:00, "Tomek Rekawek"  wrote:
>
>>Hello Angela,
>>
>>> On 16 Mar 2016, at 12:39, Angela Schreiber  wrote:
>>> 
>>> stepping into the AbstractOak2OakTest and finally
>>> RepositorySidegrade.copyState i actually see that the target
>>>NodeBuilder
>>> that results from copyWorkspace doesn't have the jcr:mixinTypes
>>> property copied from the src to the target, which consequently
>>
>>Indeed, it seems there's a bug, which causes the RepositorySidegrade to
>>skip the root node properties. I think the reason lies in the
>>calculateEffectiveIncludePaths() method, which produces an effective list
>>of paths to migrate. If we have a '/' in the input list, the method will
>>replace it with a list of '/' children and the root itself is removed
>>from the list.
>>
>>Similar issue is present in the RepositoryUpgrade, but it isn't so
>>dangerous there, as we create the root node anyway using an initializer.
>>
>>Created OAK-4128 to track this.
>>
>>However, the OAK-4128 is reproducible and present not only on the JDBC
>>destination, so I guess the random failures (including the ones on
>>Jenkins) are related to something else.
>>
>>Best regards,
>>Tomek
>>
>>-- 
>>Tomek Rękawek | Adobe Research | www.adobe.com
>>reka...@adobe.com
>>
>

Re: Failing SegmentToJdbcTest.validateMigration

[Angela Schreiber]

Hi Tomek

I create https://issues.apache.org/jira/browse/OAK-4174
in order not to mix my modifications with the upgrade
code as i consider the @ignore mark just a temp workaround
in order to keep everyone and jenkins happy :-)

kind regards
angela

On 07/04/16 14:01, "Tomek Rekawek"  wrote:

>Hello Angela,
>
>> On 07 Apr 2016, at 13:37, Angela Schreiber  wrote:
>> 
>> I will take the liberty to mark the test with an @Ignore tag when
>> committing my changes. What's your preferred way to investigate
>> this? Shall I clone the OAK-4119? Or do you want to take a closer
>> look once I am done such that you can actually experience the
>> failure?
>
>Feel free to commit your changes with the @Ignore annotation and ping me
>once the OAK-4119 is done - I'll look into the failing test then.
>
>Best regards,
>Tomek
>
>-- 
>Tomek Rękawek | Adobe Research | www.adobe.com
>reka...@adobe.com

Re: Splitdn in Oak LDAP ?

[Angela Schreiber]

Hi Kunwar

May I suggest that you create a JIRA ticket
for Oak at https://issues.apache.org/jira/browse/OAK
indicating what behaviour you would have expected?

We can then decide on whether we want to treat this as
a bug/regression or whether we'd rather decided to introduce
another 'splitdn' option in order not to compromise the
behaviour that existed since Oak 1.0.

Kind regards
Angela

On 08/04/16 13:20, "Kunwarpreet Singh Saluja"  wrote:

>Hi Oak Team,
>
>In CRX, We had an option of "splitdn" in order to maintain AD structure
>while registering AD users in CRX but now in Oak(1.2.x) we didn't find
>any similar to configure.
>
>Do we have this "splitdn" functionality available in Oak LDAP module ?
>Assuming "User DN paths"(user.makeDnPath) as similar configuration in
>Oak, it didn't work as expected.
>
>Below are the differences for the paths synced in case of CRX and Oak :-
>
>
>For CRX
>
>Path= /home/users/MIS/TSD/329421
>
>
>For Oak 1.2.x
>
>Path= /home/users/CN=Mosca\,
>Patrick/OU=TSD/OU=MIS/OU=CITYOFCHICAGO/DC=cityofchicago/DC=local/HxOYFwEec
>_hmNHfoW68d
>
>
>
>Can this be considered a bug or an expected behavior starting from Oak ?
>
>Thank you.
>
>Best Regards,
>Kunwar
>

Re: Findbug issues in the oak-code base

[Angela Schreiber]

Hi Alfu

Great to hear from you again in the Jackrabbit world!
I am definitely looking forward to your contribution and
active participation.

Sorting out Findbug issues is for sure a valuable way to
become familiar with the code base as it forces you to
dig into the details and read the code.

You may also want to look at
https://analysis.apache.org/dashboard/index/113395

In fact we never took the time to mark false positive issues
or issues we intentionally never fixed... that might also
be something to get started (to be honest I just don't know
how to mark the issues that I looked at and considered false
positives).

You will also spot that the Sonar complains about unused
fields or methods, which are there for OSGi integration but
somehow don't get properly recognised by the analysis.

But nonetheless there is for sure plenty of room for improvement
in all parts of Oak and sufficient stuff to get your hands dirty.

Kind regards
Angela



On 20/04/16 15:54, "Alfusainey Jallow"  wrote:

>Hi,
>
>I am currently going through the oak code base trying to address issues
>reported by the findbugs analysis tool[1], some of which i try to address
>in OAK-4257[2]. I did not want touch some of the concurrency issues
>reported without first writing to the list.
>
>In DocumentNodeStore (inside of oak-core plugins), syncronization is
>performed on the 'isDisposed' instance field which is declared as
>AtomicBoolean. now in the DocumentNodeStore#dispose() call, you have this:
>
>// notify background threads waiting on isDisposed
>synchronized (isDisposed) {
>  isDisposed.notifyAll();
>}
>
>
>Findbugs is warning about this saying:
>
>This method performs synchronization an object that is an instance of a
>> class from the java.util.concurrent package (or its subclasses).
>>Instances
>> of these classes have their own concurrency control mechanisms that are
>> orthogonal to the synchronization provided by the Java keyword
>> synchronized. For example, synchronizing on an AtomicBoolean will not
>> prevent other threads from modifying the AtomicBoolean.
>
>
>
>Such code may be correct, but should be carefully reviewed and documented,
>> and may confuse people who have to maintain the code at a later date.
>
>
>since i am not yet familiar with the code base, i decided to raise this
>before attempting to fix it (synchronizing on *this* object instead?) or
>may be this is intentional? the same issue is
>in DocumentNodeStore.NodeStoreTask#run() call.
>
>Most NPEs issues (possible null pointer derefence) are also reported in
>many parts of the code base and most complains results in a call to
>NodeBuilder#getProperty(String). this method can return null and the
>return
>object should always be checked for null. however, most of its usage in
>the
>code base does not explicitly check for a null-return value. is this
>intentional too?
>
>[1] https://analysis.apache.org/dashboard/index/113395
>[2] https://issues.apache.org/jira/browse/OAK-4257
>
>kind regards
>-- 
>alfu

Re: Ability to Extend the SecurityProvideImpl Gone

[Angela Schreiber]

hi tyson

the 'SecurityProvideImpl' has been replaced by a more robust
approach that makes sure the 'SecurityProvider' on gets
registered as service once all mandatory security modules
are ready. this also allows assert that the repository
gets properly initialised.

you may find additional information in the following documentation
section:

http://jackrabbit.apache.org/oak/docs/security/introduction.html

the 'SecurityProviderRegistration' is key to the understanding of
security related OSGi setup, while the 'SecurityProvideImpl' only
remains in the code base for non-OSGi setups such as we have in the
unit tests.

hope that helps
angela


On 22/04/16 12:42, "Tyson Bowman"  wrote:

>Hi all
>I am trying to extend the SecurityProvider and PermissionProvider for a
>project and the code was working prior to them upgrading their oak
>version.
>After some investigation it appears that class was removed as a service
>and
>the registration class was added. There doesn't seem to be much
>documentation or explanation or this change and would love some advice or
>examples of how to ensure your security provider gets registered. Also
>there have been a few comments about this causing problems for others so
>hopefully this can be helpful for others as well.
>
>This change
>https://github.com/apache/jackrabbit-oak/commit/81614454d9b21977ad1930c714
>41ad8f577fe013#diff-8914e351c2be2e543280ae9c9ba54770
>
>
>Thanks
>
>Tyson

Re: [VOTE] Please vote for the final name of oak-segment-next

[Angela Schreiber]

hi michael

in general i would prefer a name containing -segment-

exceptions: those names ending with a version hint or -next, which looks
quite troublesome to me... in particular as we plan to to retire the
original segment nodestore impl (or even move it to the archive
altogether).

kind regards
angela




On 26/04/16 14:11, "Michael Dürig"  wrote:

>
>oak-segment-file +1
>oak-segment-store +1
>oak-segment-tar +1
>
>Michael

Re: API proposal for - Expose URL for Blob source (OAK-1963)

[Angela Schreiber]

Hi Chetan

That's a completely different thing:
The developer of you code makes an (hopefully informed) decision to
use another super-privileged session to perform a given task.

While with your proposed change we just open the door and make it
work without enforcing an informed decision (instead just having a
note in the Javadoc (which probably gets ignored) given away the
ability to secure access to those binaries.

And just for the sake of correctness:

1. Neither JCR nor Jackrabbit nor Oak comes with a Repository.loginAsAdmin
   call. This has been discussed once in the past and we made a conscious
   decision not to do this for various reasons including security.

2. SlingRepository.loginAdministrative, which you are referring to has
been 
   a constant source of most severe vulnerabilities putting every customer
   of Sling-based applications at risk; despite the fact that the API
contract 
   (i.e. javadoc) was utterly clear about the risk and asked for using it
   responsively [1]. As you know the Apache Sling team ended up
deprecating 
   the method because it caused too many security issues!

Kind regards
Angela


[1] quote from javadoc of SlingRepository.loginAdministrative:

* NOTE: This method is intended for use by infrastructure bundles to
* access the repository and provide general services. This method MUST not
* be used to handle client requests of whatever kinds. To handle client
* requests a regular authenticated session retrieved through
* {@link #login(javax.jcr.Credentials, String)} or
* {@link Session#impersonate(javax.jcr.Credentials)} must be used.


On 05/05/16 13:50, "Chetan Mehrotra"  wrote:

>On Thu, May 5, 2016 at 5:07 PM, Francesco Mari 
>wrote:
>
>>
>> This is a totally different thing. The change to the node will be
>>committed
>> with the privileges of the session that retrieved the node. If the
>>session
>> doesn't have enough privileges to delete that node, the node will be
>> deleted, There is no escape from the security model.
>
>
>A "bad code" when passes a node backed via admin session can still do bad
>thing as admin session has all the privileges. In same way if a bad code
>is
>passed a file handle then it can cause issue. So I am still not sure on
>the
>attack vector which we are defending against.
>
>Chetan Mehrotra

Re: API proposal for - Expose URL for Blob source (OAK-1963)

[Angela Schreiber]

Hi Ian

On 04/05/16 18:37, "Ian Boston"  wrote:
>[...] The locations will certainly probably leak
>outside the context of an Oak session so the API contract should make it
>clear that the code using a direct location needs to behave responsibly.

See my reply to Chetan, who was referring to
SlingRepository.loginAdministrative
which always had a pretty clear API contract wrt responsible usage.

As a matter of fact (and I guess you are aware of this) it turned into a
total nightmare with developers using it just everywhere, ignoring not
only 
the API contract but also all concerns raised for years. This can even
been seen in Apache Sling code base itself.

So, I am quite pessimistic about responsible usage and API contract
and definitely prefer an API implementation that effectively enforces
the contract.

Vulnerable by design is IMHO a bad guideline for introducing new APIs.
>From my experiences they backfire usually sooner than later and need
to be abandoned again... so, I'd rather aim for a properly secured
solution right from the beginning.

Kind regards
Angela

>
>Best Regards
>Ian
>
>
>On 3 May 2016 at 15:36, Chetan Mehrotra  wrote:
>
>> Hi Team,
>>
>> For OAK-1963 we need to allow access to actaul Blob location say in form
>> File instance or S3 object id etc. This access is need to perform
>>optimized
>> IO operation around binary object e.g.
>>
>> 1. The File object can be used to spool the file content with zero copy
>> using NIO by accessing the File Channel directly [1]
>>
>> 2. Client code can efficiently replicate a binary stored in S3 by having
>> direct access to S3 object using copy operation
>>
>> To allow such access we would need a new API in the form of
>> AdaptableBinary.
>>
>> API
>> ===
>>
>> public interface AdaptableBinary {
>>
>> /**
>>  * Adapts the binary to another type like File, URL etc
>>  *
>>  * @param  The generic type to which this binary is
>> adapted
>>  *to
>>  * @param type The Class object of the target type, such as
>>  *File.class
>>  * @return The adapter target or null if the binary
>>cannot
>>  * adapt to the requested type
>>  */
>>  AdapterType adaptTo(Class type);
>> }
>>
>> Usage
>> =
>>
>> Binary binProp = node.getProperty("jcr:data").getBinary();
>>
>> //Check if Binary is of type AdaptableBinary
>> if (binProp instanceof AdaptableBinary){
>>  AdaptableBinary adaptableBinary = (AdaptableBinary) binProp;
>>
>> //Adapt it to File instance
>>  File file = adaptableBinary.adaptTo(File.class);
>> }
>>
>>
>>
>> The Binary instance returned by Oak
>> i.e. org.apache.jackrabbit.oak.plugins.value.BinaryImpl would then
>> implement this interface and calling code can then check the type and
>>cast
>> it and then adapt it
>>
>> Key Points
>> 
>>
>> 1. Depending on backing BlobStore the binary can be adapted to various
>> types. For FileDataStore it can be adapted to File. For S3DataStore it
>>can
>> either be adapted to URL or some S3DataStore specific type.
>>
>> 2. Security - Thomas suggested that for better security the ability to
>> adapt should be restricted based on session permissions. So if the user
>>has
>> required permission then only adaptation would work otherwise null
>>would be
>> returned.
>>
>> 3. Adaptation proposal is based on Sling Adaptable [2]
>>
>> 4. This API is for now exposed only at JCR level. Not sure should we do
>>it
>> at Oak level as Blob instance are currently not bound to any session. So
>> proposal is to place this in 'org.apache.jackrabbit.oak.api' package
>>
>> Kindly provide your feedback! Also any suggestion/guidance around how
>>the
>> access control be implemented
>>
>> Chetan Mehrotra
>> [1] http://www.ibm.com/developerworks/library/j-zerocopy/
>> [2]
>>
>> 
>>https://sling.apache.org/apidocs/sling5/org/apache/sling/api/adapter/Adap
>>table.html
>>

Re: API proposal for - Expose URL for Blob source (OAK-1963)

[Angela Schreiber]

Hi 

Same here... Francesco already summarised my concerns very nicely.

The links Michael provided below resonate what came to my mind
regarding past discussions around binary handling in the JCR/Jackrabbit
API and in Oak.

I also distinctly remember that one key argument for the current
design of the Oak Blob API was the fact that the access to
the binaries created through this API is properly secured due
to the fact that they (or their references) are read and written
from/to the Oak repository through calls that are subject to
the configured security setup i.e. are always secured.

@Chetan, regarding your original comment wrt security:

> 2. Security - Thomas suggested that for better security the ability to
> adapt should be restricted based on session permissions. So if the user
>has
> required permission then only adaptation would work otherwise null would
>be
> returned.

As others said before I don't think that this is the critical
part from a security point of view... The access to the property
is secured by the authorization model present with the given
repository. IMO the troublesome part comes only _after_ the adaption
to something else, where you loose the ability to enforce the
constraints imposed by the permission setup.

After all I am not convinced that we should rush this API into the
code base at the current state... from my PoV there are too many valid
concerns. And honestly, I weight the architectural and consistency
concerns even higher than the security issues.

Having said this: I'd rather take one step back again and start looking
for other approaches that would allow us to the address the issue(s)
at hand in a better way.

Kind regards
Angela

On 09/05/16 10:58, "Michael Dürig"  wrote:

>
>Hi,
>
>I very much share Francesco's concerns here. Unconditionally exposing
>access to operation system resources underlying Oak's inner working is
>troublesome for various reasons:
>
>- who owns the resource? Who coordinates (concurrent) access to it and
>how? What are the correctness and performance implications here (races,
>deadlock, corruptions, JCR semantics)?
>
>- it limits implementation freedom and hinders further evolution
>(chunking, de-duplication, content based addressing, compression, gc,
>etc.) for data stores.
>
>- bypassing JCR's security model
>
>Pretty much all of this has been discussed in the scope of
>https://issues.apache.org/jira/browse/JCR-3534 and
>https://issues.apache.org/jira/browse/OAK-834. So I suggest to review
>those discussions before we jump to conclusion.
>
>
>Also what is the use case requiring such a vast API surface? Can't we
>come up with an API that allows the blobs to stay under control of Oak?
>If not, this is probably an indication that those blobs shouldn't go
>into Oak but just references to it as Francesco already proposed.
>Anything else is whether fish nor fowl: you can't have the JCR goodies
>but at the same time access underlying resources at will.
>
>Michael
>
>
>
>On 5.5.16 11:00 , Francesco Mari wrote:
>> This proposal introduces a huge leak of abstractions and has deep
>>security
>> implications.
>>
>> I guess that the reason for this proposal is that some users of Oak
>>would
>> like to perform some operations on binaries in a more performant way by
>> leveraging the way those binaries are stored. If this is the case, I
>> suggest those users to evaluate an applicative solution implemented on
>>top
>> of the JCR API.
>>
>> If a user needs to store some important binary data (files, images,
>>etc.)
>> in an S3 bucket or on the file system for performance reasons, this
>> shouldn't affect how Oak handles blobs internally. If some assets are of
>> special interest for the user, then the user should bypass Oak and take
>> care of the storage of those assets directly. Oak can be used to store
>> *references* to those assets, that can be used in user code to
>>manipulate
>> the assets in his own business logic.
>>
>> If the scenario I outlined is not what inspired this proposal, I would
>>like
>> to know more about the reasons why this proposal was brought up. Which
>> problems are we going to solve with this API? Is there a more concrete
>>use
>> case that we can use as a driving example?
>>
>> 2016-05-05 10:06 GMT+02:00 Davide Giannella :
>>
>>> On 04/05/2016 17:37, Ian Boston wrote:
 Hi,
 If the File or URL is writable, will writing to the location cause
issues
 for Oak ?
 IIRC some Oak DS implementations use a digest of the content to
determine
 the location in the DS, so changing the content via Oak will change
the
 location, but changing the content via the File or URL wont. If I
didn't
 remember correctly, then ignore the concern.  Fully supportive of the
 approach, as a consumer of Oak. The locations will certainly probably
>>> leak
 outside the context of an Oak session so the API contract should make
it
 clear that the code using a direct location needs to behave
responsi

Re: API proposal for - Expose URL for Blob source (OAK-1963)

[Angela Schreiber]

Hi Ian

>Fair enough, provided there is a solution that addresses the issue Chetan
>is trying to address.

That's what we are all looking for :)

>The alternative, for some applications, seems to store the binary data
>outside Oak, which defeats the purpose completely.

You mean with the current setup, right?

That might well be... while I haven't been involved with a concrete
case I wouldn't categorically reject that this might in same cases
even be the right solution.
But maybe I am biased due to the fact that we also have a big
community that effectively stores and manages their user/group
accounts outside the repository and where I am seeing plenty of
trouble with the conception that those accounts _must_ be synced
(i.e. copied) into the repo.

So, I'd definitely like to understand why you think that this
"completely defeats the purpose". I agree that it's not always
desirable but nevertheless there might be valid use-cases.

>I don't have a perfect handle on the issue he is trying to address or what
>would be an acceptable solution, but I suspect the only solution that is
>not vulnerable by design will a solution that abstracts all the required
>functionality behind an Oak API (ie no S3Object, File object or anything
>that could leak) and then provide all the required functionality with an
>acceptable level of performance in the implementation. That is doable, but
>a lot more work.

Not sure about that :-)
Quite frankly I would very much appreciate if took the time to collect
and write down the required (i.e. currently known and expected)
functionality.

Then look at the requirements and look what is wrong with the current
API that we can't meet those requirements:
- is it just missing API extensions that can be added with moderate effort?
- are there fundamental problems with the current API that we needed to
address?
- maybe we even have intrinsic issues with the way we think about the role
of the repo?

IMHO, sticking to kludges might look promising on a short term but
I am convinced that we are better off with a fundamental analysis of
the problems... after all the Binary topic comes up on a regular basis.
That leaves me with the impression that yet another tiny extra and
adaptables won't really address the core issues.

Kind regards
Angela



>
>
>Best Regards
>Ian
>
>
>>
>> Kind regards
>> Angela
>>
>> >
>> >Best Regards
>> >Ian
>> >
>> >
>> >On 3 May 2016 at 15:36, Chetan Mehrotra 
>> wrote:
>> >
>> >> Hi Team,
>> >>
>> >> For OAK-1963 we need to allow access to actaul Blob location say in
>>form
>> >> File instance or S3 object id etc. This access is need to perform
>> >>optimized
>> >> IO operation around binary object e.g.
>> >>
>> >> 1. The File object can be used to spool the file content with zero
>>copy
>> >> using NIO by accessing the File Channel directly [1]
>> >>
>> >> 2. Client code can efficiently replicate a binary stored in S3 by
>>having
>> >> direct access to S3 object using copy operation
>> >>
>> >> To allow such access we would need a new API in the form of
>> >> AdaptableBinary.
>> >>
>> >> API
>> >> ===
>> >>
>> >> public interface AdaptableBinary {
>> >>
>> >> /**
>> >>  * Adapts the binary to another type like File, URL etc
>> >>  *
>> >>  * @param  The generic type to which this binary is
>> >> adapted
>> >>  *to
>> >>  * @param type The Class object of the target type, such as
>> >>  *File.class
>> >>  * @return The adapter target or null if the binary
>> >>cannot
>> >>  * adapt to the requested type
>> >>  */
>> >>  AdapterType adaptTo(Class type);
>> >> }
>> >>
>> >> Usage
>> >> =
>> >>
>> >> Binary binProp = node.getProperty("jcr:data").getBinary();
>> >>
>> >> //Check if Binary is of type AdaptableBinary
>> >> if (binProp instanceof AdaptableBinary){
>> >>  AdaptableBinary adaptableBinary = (AdaptableBinary) binProp;
>> >>
>> >> //Adapt it to File instance
>> >>  File file = adaptableBinary.adaptTo(File.class);
>> >> }
>> >>
>> >>
>> >>
>> >> The Binary instance returned by Oak
>> >> i.e. org.apache.jackrabbit.oak.plugins.value.BinaryImpl would then
>> >> implement this interface and calling code can then check the type and
>> >>cast
>> >> it and then adapt it
>> >>
>> >> Key Points
>> >> 
>> >>
>> >> 1. Depending on backing BlobStore the binary can be adapted to
>>various
>> >> types. For FileDataStore it can be adapted to File. For S3DataStore
>>it
>> >>can
>> >> either be adapted to URL or some S3DataStore specific type.
>> >>
>> >> 2. Security - Thomas suggested that for better security the ability
>>to
>> >> adapt should be restricted based on session permissions. So if the
>>user
>> >>has
>> >> required permission then only adaptation would work otherwise null
>> >>would be
>> >> returned.
>> >>
>> >> 3. Adaptation proposal is based on Sling Adaptable [2]
>> >>
>> >> 4. This API is for now exposed only at JCR level. Not sure should we
>>do
>> >>it
>> >> at Oak 

Re: API proposal for - Expose URL for Blob source (OAK-1963)

[Angela Schreiber]

Hi Chetan

IMHO your original mail didn't write down the fundamental analysis
but instead presented the solution for every the 2 case I was
lacking the information _why_ this is needed.

Both have been answered in private conversions only (1 today in
the oak call and 2 in a private discussion with tom). And
having heard didn't make me more confident that the solution
you propose is the right thing to do.

Kind regards
Angela

On 11/05/16 12:17, "Chetan Mehrotra"  wrote:

>Hi Angela,
>
>On Tue, May 10, 2016 at 9:49 PM, Angela Schreiber 
>wrote:
>
>> Quite frankly I would very much appreciate if took the time to collect
>> and write down the required (i.e. currently known and expected)
>> functionality.
>>
>> Then look at the requirements and look what is wrong with the current
>> API that we can't meet those requirements:
>> - is it just missing API extensions that can be added with moderate
>>effort?
>> - are there fundamental problems with the current API that we needed to
>> address?
>> - maybe we even have intrinsic issues with the way we think about the
>>role
>> of the repo?
>>
>> IMHO, sticking to kludges might look promising on a short term but
>> I am convinced that we are better off with a fundamental analysis of
>> the problems... after all the Binary topic comes up on a regular basis.
>> That leaves me with the impression that yet another tiny extra and
>> adaptables won't really address the core issues.
>>
>
>Makes sense.
>
>Have a look in of the initial mail in the thread at [1] which talks about
>the 2 usecase I know of. The image rendition usecase manifest itself in
>one
>form or other, basically providing access to Native programs via file path
>reference.
>
>The approach proposed so far would be able to address them and hence
>closer
>to "is it just missing API extensions that can be added with moderate
>effort?". If there are any other approach we can address both of the
>referred usecases then we implement them.
>
>Let me know if more details are required. If required I can put it up on a
>wiki page also.
>
>Chetan Mehrotra
>[1]
>http://markmail.org/thread/6mq4je75p64c5nyn#query:+page:1+mid:zv5dzsgmoegu
>pd7l+state:results

Re: svn commit: r1743322 - in /jackrabbit/oak/trunk/oak-auth-external/src/test/java/org/apache/jackrabbit/oak/spi/security/authentication/external: TestIdentityProvider.java impl/jmx/SyncMBeanImplTest

[Angela Schreiber]

hi julian

On 13/05/16 15:13, "Julian Reschke"  wrote:

>...with this change,

change? hasn't the test just been introduced with that commit?
*confused*

>testSyncExternalUsersLastSyncedProperty fails
>reliably on my machines, because the two timestamps are the same.

ok... 

>
>Maybe there's code missing ensuring that System.currentTimeMillis()
>actually changed before doing the operation that's suppose to lead to a
>new timestamp?

that might well be. i will take a look.

thanks for reporting
angela

>
>Best regards, Julian
>
>
>On 2016-05-11 09:12, ang...@apache.org wrote:
>> Author: angela
>> Date: Wed May 11 07:12:43 2016
>> New Revision: 1743322
>>
>> URL: http://svn.apache.org/viewvc?rev=1743322&view=rev
>> Log:
>> OAK-4264 : Improve testing of SyncMBeanImpl (WIP)
>>
>> Modified:
>> 
>>jackrabbit/oak/trunk/oak-auth-external/src/test/java/org/apache/jackrabbi
>>t/oak/spi/security/authentication/external/TestIdentityProvider.java
>> 
>>jackrabbit/oak/trunk/oak-auth-external/src/test/java/org/apache/jackrabbi
>>t/oak/spi/security/authentication/external/impl/jmx/SyncMBeanImplTest.jav
>>a
>>
>> Modified: 
>>jackrabbit/oak/trunk/oak-auth-external/src/test/java/org/apache/jackrabbi
>>t/oak/spi/security/authentication/external/TestIdentityProvider.java
>> URL: 
>>http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-auth-external/src/t
>>est/java/org/apache/jackrabbit/oak/spi/security/authentication/external/T
>>estIdentityProvider.java?rev=1743322&r1=1743321&r2=1743322&view=diff
>> 
>>=
>>=
>> --- 
>>jackrabbit/oak/trunk/oak-auth-external/src/test/java/org/apache/jackrabbi
>>t/oak/spi/security/authentication/external/TestIdentityProvider.java
>>(original)
>> +++ 
>>jackrabbit/oak/trunk/oak-auth-external/src/test/java/org/apache/jackrabbi
>>t/oak/spi/security/authentication/external/TestIdentityProvider.java Wed
>>May 11 07:12:43 2016
>> @@ -40,14 +40,14 @@ public class TestIdentityProvider implem
>>  private final Map externalUsers = new
>>HashMap();
>>
>>  public TestIdentityProvider() {
>> -addGroup(new TestGroup("aa"));
>> -addGroup(new TestGroup("aaa"));
>> -addGroup(new TestGroup("a").withGroups("aa", "aaa"));
>> -addGroup(new TestGroup("b").withGroups("a"));
>> -addGroup(new TestGroup("c"));
>> -addGroup(new TestGroup("secondGroup"));
>> +addGroup(new TestGroup("aa", getName()));
>> +addGroup(new TestGroup("aaa", getName()));
>> +addGroup(new TestGroup("a", getName()).withGroups("aa",
>>"aaa"));
>> +addGroup(new TestGroup("b", getName()).withGroups("a"));
>> +addGroup(new TestGroup("c", getName()));
>> +addGroup(new TestGroup("secondGroup", getName()));
>>
>> -addUser(new TestUser(ID_TEST_USER)
>> +addUser(new TestUser(ID_TEST_USER, getName())
>>  .withProperty("name", "Test User")
>>  .withProperty("profile/name", "Public Name")
>>  .withProperty("profile/age", 72)
>> @@ -55,7 +55,7 @@ public class TestIdentityProvider implem
>>  .withGroups("a", "b", "c")
>>  );
>>
>> -addUser(new TestUser(ID_SECOND_USER)
>> +addUser(new TestUser(ID_SECOND_USER, getName())
>>  .withProperty("profile/name", "Second User")
>>  .withProperty("age", 24)
>>  .withProperty("col", ImmutableList.of("v1", "v2",
>>"v3"))
>> @@ -141,17 +141,17 @@ public class TestIdentityProvider implem
>>  private final Map props = new HashMap>Object>();
>>
>>  public TestIdentity() {
>> -this("externalId", "principalName");
>> +this("externalId", "principalName", "test");
>>  }
>>
>>  public TestIdentity(@Nonnull String userId) {
>> -this(userId, userId);
>> +this(userId, userId, "test");
>>  }
>>
>> -public TestIdentity(@Nonnull String userId, @Nonnull String
>>principalName) {
>> +public TestIdentity(@Nonnull String userId, @Nonnull String
>>principalName, @Nonnull String idpName) {
>>  this.userId = userId;
>>  this.principalName = principalName;
>> -id = new ExternalIdentityRef(userId, "test");
>> +id = new ExternalIdentityRef(userId, idpName);
>>  }
>>
>>  public TestIdentity(@Nonnull ExternalIdentity base) {
>> @@ -202,7 +202,7 @@ public class TestIdentityProvider implem
>>
>>  protected TestIdentity withGroups(String ... grps) {
>>  for (String grp: grps) {
>> -groups.add(new ExternalIdentityRef(grp, "test"));
>> +groups.add(new ExternalIdentityRef(grp,
>>id.getProviderName()));
>>  }
>>  return this;
>>  }
>> @@ -210,8 +210,8 @@ public class TestIdentityProvider implem
>>
>>  private static class TestUser extends TestIdentity implements
>>External

Re: API proposal for - Expose URL for Blob source (OAK-1963)

[Angela Schreiber]

Hi Oak-Devs

Just for the record: This topic has been discussed in a Adobe
internal Oak-coordination call last Wednesday.

Michael Marth first provided some background information and
we discussed the various concerns mentioned in this thread
and tried to identity the core issue(s).

Marcel, Michael Duerig and Thomas proposed alternative approaches
on how to address the original issues that lead to the API
proposal, which all would avoid leaking out information about
the internal blob handling.

Unfortunately we ran out of time and didn't conclude the call
with an agreement on how to proceed.

>From my perception the concerns raised here could not be resolved
by the additional information.

I would suggest that we try to continue the discussion here
on the list. Maybe with a summary of the alternative proposals?

Kind regards
Angela

On 11/05/16 15:38, "Ian Boston"  wrote:

>Hi,
>
>On 11 May 2016 at 14:21, Marius Petria  wrote:
>
>> Hi,
>>
>> I would add another use case in the same area, even if it is more
>> problematic from the point of view of security. To better support load
>> spikes an application could return 302 redirects to  (signed) S3 urls
>>such
>> that binaries are fetched directly from S3.
>>
>
>Perhaps that question exposes the underlying requirement for some
>downstream users.
>
>This is a question, not a statement:
>
>If the application using Oak exposed a RESTfull API that had all the same
>functionality as [1], and was able to perform at the scale of S3, and had
>the same security semantics as Oak, would applications that are needing
>direct access to S3 or a File based datastore be able to use that API in
>preference ?
>
>Is this really about issues with scalability and performance rather than a
>fundamental need to drill deep into the internals of Oak ? If so,
>shouldn't
>the scalability and performance be fixed ? (assuming its a real concern)
>
>
>
>
>>
>> (if this can already be done or you think is not really related to the
>> other two please disregard).
>>
>
>AFAIK this is not possible at the moment. If it was deployments could use
>nginX X-SendFile and other request offloading mechanisms.
>
>Best Regards
>Ian
>
>
>1 http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectOps.html
>
>
>>
>> Marius
>>
>>
>>
>> On 5/11/16, 1:41 PM, "Angela Schreiber"  wrote:
>>
>> >Hi Chetan
>> >
>> >IMHO your original mail didn't write down the fundamental analysis
>> >but instead presented the solution for every the 2 case I was
>> >lacking the information _why_ this is needed.
>> >
>> >Both have been answered in private conversions only (1 today in
>> >the oak call and 2 in a private discussion with tom). And
>> >having heard didn't make me more confident that the solution
>> >you propose is the right thing to do.
>> >
>> >Kind regards
>> >Angela
>> >
>> >On 11/05/16 12:17, "Chetan Mehrotra"  wrote:
>> >
>> >>Hi Angela,
>> >>
>> >>On Tue, May 10, 2016 at 9:49 PM, Angela Schreiber 
>> >>wrote:
>> >>
>> >>> Quite frankly I would very much appreciate if took the time to
>>collect
>> >>> and write down the required (i.e. currently known and expected)
>> >>> functionality.
>> >>>
>> >>> Then look at the requirements and look what is wrong with the
>>current
>> >>> API that we can't meet those requirements:
>> >>> - is it just missing API extensions that can be added with moderate
>> >>>effort?
>> >>> - are there fundamental problems with the current API that we
>>needed to
>> >>> address?
>> >>> - maybe we even have intrinsic issues with the way we think about
>>the
>> >>>role
>> >>> of the repo?
>> >>>
>> >>> IMHO, sticking to kludges might look promising on a short term but
>> >>> I am convinced that we are better off with a fundamental analysis of
>> >>> the problems... after all the Binary topic comes up on a regular
>>basis.
>> >>> That leaves me with the impression that yet another tiny extra and
>> >>> adaptables won't really address the core issues.
>> >>>
>> >>
>> >>Makes sense.
>> >>
>> >>Have a look in of the initial mail in the thread at [1] which talks
>>about
>> >>the 2 usecase I know of. The image rendition usecase manifest itself
>>in
>> >>one
>> >>form or other, basically providing access to Native programs via file
>> path
>> >>reference.
>> >>
>> >>The approach proposed so far would be able to address them and hence
>> >>closer
>> >>to "is it just missing API extensions that can be added with moderate
>> >>effort?". If there are any other approach we can address both of the
>> >>referred usecases then we implement them.
>> >>
>> >>Let me know if more details are required. If required I can put it up
>>on
>> a
>> >>wiki page also.
>> >>
>> >>Chetan Mehrotra
>> >>[1]
>> >>
>> 
>>http://markmail.org/thread/6mq4je75p64c5nyn#query:+page:1+mid:zv5dzsgmoeg
>>u
>> >>pd7l+state:results
>> >
>>

Re: svn commit: r1744672 - in /jackrabbit/oak/trunk/oak-run: pom.xml src/main/java/org/apache/jackrabbit/oak/benchmark/BenchmarkRunner.java src/main/java/org/apache/jackrabbit/oak/benchmark/authentica

[Angela Schreiber]

uh... sorry for that! i will revert and fix it.
thanks for the heads up

angela

On 20/05/16 16:00, "Francesco Mari"  wrote:

>Hi Angela,
>
>the "org.apache.sling.testing.osgi-mock" dependency has an empty scope in
>oak-run/pom.xml. Even if I change the scope to "test", I have a
>compilation
>error when building oak-run.
>
>[ERROR]
>/Users/mari/src/svn/oak/trunk/oak-run/src/main/java/org/apache/jackrabbit/
>oak/benchmark/authentication/external/AbstractExternalTest.java:[68,47]
>error: package org.apache.sling.testing.mock.osgi.junit does not exist
>
>[ERROR]
>/Users/mari/src/svn/oak/trunk/oak-run/src/main/java/org/apache/jackrabbit/
>oak/benchmark/authentication/external/AbstractExternalTest.java:[183,24]
>error: cannot find symbol
>
>[ERROR]   symbol: class OsgiContext
>
>/Users/mari/src/svn/oak/trunk/oak-run/src/main/java/org/apache/jackrabbit/
>oak/benchmark/authentication/external/AbstractExternalTest.java:[183,50]
>error: cannot find symbol
>
>[INFO] 3 errors
>
>Can you review this?
>
>-- Forwarded message --
>From: 
>Date: 2016-05-20 10:26 GMT+02:00
>Subject: svn commit: r1744672 - in /jackrabbit/oak/trunk/oak-run: pom.xml
>src/main/java/org/apache/jackrabbit/oak/benchmark/BenchmarkRunner.java
>src/main/java/org/apache/jackrabbit/oak/benchmark/authentication/external/
>AbstractExternalTest.java
>To: oak-comm...@jackrabbit.apache.org
>
>
>Author: angela
>Date: Fri May 20 08:26:23 2016
>New Revision: 1744672
>
>URL: http://svn.apache.org/viewvc?rev=1744672&view=rev
>Log:
>OAK-4385 : Benchmarks: proper init of ExternalPrincipalConfiguration with
>dynamicMembership
>
>Modified:
>jackrabbit/oak/trunk/oak-run/pom.xml
>
>jackrabbit/oak/trunk/oak-run/src/main/java/org/apache/jackrabbit/oak/bench
>mark/BenchmarkRunner.java
>
>jackrabbit/oak/trunk/oak-run/src/main/java/org/apache/jackrabbit/oak/bench
>mark/authentication/external/AbstractExternalTest.java
>
>Modified: jackrabbit/oak/trunk/oak-run/pom.xml
>URL:
>http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-run/pom.xml?rev=1744
>672&r1=1744671&r2=1744672&view=diff
>==
>
>--- jackrabbit/oak/trunk/oak-run/pom.xml (original)
>+++ jackrabbit/oak/trunk/oak-run/pom.xml Fri May 20 08:26:23 2016
>@@ -427,6 +427,12 @@
>   com.google.code.findbugs
>   jsr305
> 
>+
>+
>+  org.apache.sling
>+  org.apache.sling.testing.osgi-mock
>+  
>+
>
> 
> 
>
>Modified:
>jackrabbit/oak/trunk/oak-run/src/main/java/org/apache/jackrabbit/oak/bench
>mark/BenchmarkRunner.java
>URL:
>http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-run/src/main/java/or
>g/apache/jackrabbit/oak/benchmark/BenchmarkRunner.java?rev=1744672&r1=1744
>671&r2=1744672&view=diff
>==
>
>---
>jackrabbit/oak/trunk/oak-run/src/main/java/org/apache/jackrabbit/oak/bench
>mark/BenchmarkRunner.java
>(original)
>+++
>jackrabbit/oak/trunk/oak-run/src/main/java/org/apache/jackrabbit/oak/bench
>mark/BenchmarkRunner.java
>Fri May 20 08:26:23 2016
>@@ -131,6 +131,8 @@ public class BenchmarkRunner {
> .defaultsTo(Boolean.FALSE);
> OptionSpec supportedPaths =
>parser.accepts("supportedPaths", "Supported paths in composite setup.")
>
> .withOptionalArg().ofType(String.class).withValuesSeparatedBy(',');
>+OptionSpec dynamicMembership =
>parser.accepts("dynamicMembership", "Enable dynamic membership handling
>during synchronisation of external users.")
>+
>.withOptionalArg().ofType(Boolean.class).defaultsTo(Boolean.FALSE);
> OptionSpec autoMembership =
>parser.accepts("autoMembership", "Ids of those groups a given external
>identity automatically become member of.")
>
> .withOptionalArg().ofType(String.class).withValuesSeparatedBy(',');
> OptionSpec nonOption = parser.nonOptions();
>@@ -391,9 +393,9 @@ public class BenchmarkRunner {
> new ReplicaCrashResilienceTest(),
>
> // benchmarks for oak-auth-external
>-new ExternalLoginTest(numberOfUsers.value(options),
>numberOfGroups.value(options), expiration.value(options), false,
>autoMembership.values(options)),
>-new SyncAllExternalUsersTest(numberOfUsers.value(options),
>numberOfGroups.value(options), expiration.value(options), false,
>autoMembership.values(options)),
>-new SyncExternalUsersTest(numberOfUsers.value(options),
>numberOfGroups.value(options), expiration.value(options), false,
>autoMembership.values(options), batchSize.value(options))
>+new ExternalLoginTest(numberOfUsers.value(options),
>numberOfGroups.value(options), expiration.value(options),
>dynamicMembership.value(options), autoMembership.values(options)),
>+new SyncAllExternalUsersTest(numberOfUsers.value(options),
>numberOfGroups.value(options), expiration.value(options),
>dynamicMembership.value(options), autoMembership.values(options)),
>+new SyncExterna

Re: svn commit: r1744672 - in /jackrabbit/oak/trunk/oak-run: pom.xml src/main/java/org/apache/jackrabbit/oak/benchmark/BenchmarkRunner.java src/main/java/org/apache/jackrabbit/oak/benchmark/authentica

[Angela Schreiber]

hi francesco

i slightly refactored the benchmark; imo the junit dependency
doesn't need to have a changed scope with that modification.
otherwise let me know...

thanks again
angela

On 23/05/16 10:49, "Francesco Mari"  wrote:

>I looked a little bit deeper into it. There is no need to revert. The
>problem can be solved by explicitly setting the scope of
>"org.apache.sling.testing.osgi-mock" and "junit" to compile.
>
>2016-05-23 9:14 GMT+02:00 Angela Schreiber :
>
>> uh... sorry for that! i will revert and fix it.
>> thanks for the heads up
>>
>> angela
>>
>> On 20/05/16 16:00, "Francesco Mari"  wrote:
>>
>> >Hi Angela,
>> >
>> >the "org.apache.sling.testing.osgi-mock" dependency has an empty scope
>>in
>> >oak-run/pom.xml. Even if I change the scope to "test", I have a
>> >compilation
>> >error when building oak-run.
>> >
>> >[ERROR]
>> 
>>>/Users/mari/src/svn/oak/trunk/oak-run/src/main/java/org/apache/jackrabbi
>>>t/
>> >oak/benchmark/authentication/external/AbstractExternalTest.java:[68,47]
>> >error: package org.apache.sling.testing.mock.osgi.junit does not exist
>> >
>> >[ERROR]
>> 
>>>/Users/mari/src/svn/oak/trunk/oak-run/src/main/java/org/apache/jackrabbi
>>>t/
>> 
>>>oak/benchmark/authentication/external/AbstractExternalTest.java:[183,24]
>> >error: cannot find symbol
>> >
>> >[ERROR]   symbol: class OsgiContext
>> >
>> 
>>>/Users/mari/src/svn/oak/trunk/oak-run/src/main/java/org/apache/jackrabbi
>>>t/
>> 
>>>oak/benchmark/authentication/external/AbstractExternalTest.java:[183,50]
>> >error: cannot find symbol
>> >
>> >[INFO] 3 errors
>> >
>> >Can you review this?
>> >
>> >-- Forwarded message --
>> >From: 
>> >Date: 2016-05-20 10:26 GMT+02:00
>> >Subject: svn commit: r1744672 - in /jackrabbit/oak/trunk/oak-run:
>>pom.xml
>> >src/main/java/org/apache/jackrabbit/oak/benchmark/BenchmarkRunner.java
>> 
>>>src/main/java/org/apache/jackrabbit/oak/benchmark/authentication/externa
>>>l/
>> >AbstractExternalTest.java
>> >To: oak-comm...@jackrabbit.apache.org
>> >
>> >
>> >Author: angela
>> >Date: Fri May 20 08:26:23 2016
>> >New Revision: 1744672
>> >
>> >URL: http://svn.apache.org/viewvc?rev=1744672&view=rev
>> >Log:
>> >OAK-4385 : Benchmarks: proper init of ExternalPrincipalConfiguration
>>with
>> >dynamicMembership
>> >
>> >Modified:
>> >jackrabbit/oak/trunk/oak-run/pom.xml
>> >
>> 
>>>jackrabbit/oak/trunk/oak-run/src/main/java/org/apache/jackrabbit/oak/ben
>>>ch
>> >mark/BenchmarkRunner.java
>> >
>> 
>>>jackrabbit/oak/trunk/oak-run/src/main/java/org/apache/jackrabbit/oak/ben
>>>ch
>> >mark/authentication/external/AbstractExternalTest.java
>> >
>> >Modified: jackrabbit/oak/trunk/oak-run/pom.xml
>> >URL:
>> >
>> 
>>http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-run/pom.xml?rev=174
>>4
>> >672&r1=1744671&r2=1744672&view=diff
>> 
>>>
>>>==
>> >
>> >--- jackrabbit/oak/trunk/oak-run/pom.xml (original)
>> >+++ jackrabbit/oak/trunk/oak-run/pom.xml Fri May 20 08:26:23 2016
>> >@@ -427,6 +427,12 @@
>> >   com.google.code.findbugs
>> >   jsr305
>> > 
>> >+
>> >+
>> >+  org.apache.sling
>> >+  org.apache.sling.testing.osgi-mock
>> >+  
>> >+
>> >
>> > 
>> > 
>> >
>> >Modified:
>> 
>>>jackrabbit/oak/trunk/oak-run/src/main/java/org/apache/jackrabbit/oak/ben
>>>ch
>> >mark/BenchmarkRunner.java
>> >URL:
>> >
>> 
>>http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-run/src/main/java/o
>>r
>> 
>>>g/apache/jackrabbit/oak/benchmark/BenchmarkRunner.java?rev=1744672&r1=17
>>>44
>> >671&r2=1744672&view=diff
>> 
>>>
>>>==
>> >
>> >---
>> 
>>>jackrabbit/oak/trunk/oak-run/src/main/java/org/apache/jackrabbit/oak/ben
>>>ch
>> >mark/BenchmarkR

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.3

[Angela Schreiber]

hi julian

that looks pretty similar to OAK-4382

they have in common that they sync (or should sync) group-membership with
infinite nesting (in the test-setup the nesting in anyway just 2).

but i can't reproduce neither issue on my machine; however, all those
tests failing on your machine lack the 'deep' groups i.e. those groups
the synced users is not declared but only inherited member of.

not sure how to sort that out if i can't reproduce it.

kind regards
angela

On 06/06/16 18:02, "Julian Reschke"  wrote:

>On 2016-06-06 17:04, Davide Giannella wrote:
>> A candidate for the Jackrabbit Oak 1.5.3 release is available at:
>>
>> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.5.3/
>>
>> The release candidate is a zip archive of the sources in:
>> ...
>
>
>I'm getting test failures in oak-auth-external:
>
>> 
>>testGetGroupMembershipExternalUserInfiniteDepth(org.apache.jackrabbit.oak
>>.spi.security.authentication.external.impl.principal.PrincipalProviderAut
>>oMembershipTest)  Time elapsed: 0.051 sec  <<< FAILURE!
>> java.lang.AssertionError:
>>expected:<[org.apache.jackrabbit.oak.security.user.GroupImpl$GroupPrincip
>>al:ptestGroup52594cfe-26c9-4db9-838b-a607ff4c3e8c,
>>org.apache.jackrabbit.oak.spi.security.principal.PrincipalImpl:aaa,
>>org.apache.jackrabbit.oak.spi.security.principal.PrincipalImpl:b,
>>org.apache.jackrabbit.oak.spi.security.principal.PrincipalImpl:c,
>>org.apache.jackrabbit.oak.spi.security.principal.PrincipalImpl:a,
>>org.apache.jackrabbit.oak.spi.security.principal.PrincipalImpl:aa]> but
>>was:<[org.apache.jackrabbit.oak.security.user.GroupImpl$GroupPrincipal:pt
>>estGroup52594cfe-26c9-4db9-838b-a607ff4c3e8c,
>>org.apache.jackrabbit.oak.spi.security.authentication.external.impl.princ
>>ipal.ExternalGroupPrincipalProvider$ExternalGroupPrincipal:b,
>>org.apache.jackrabbit.oak.spi.security.authentication.external.impl.princ
>>ipal.ExternalGroupPrincipalProvider$ExternalGroupPrincipal:c,
>>org.apache.jackrabbit.oak.spi.security.authentication.external.impl.princ
>>ipal.ExternalGroupPrincipalProvider$ExternalGroupPrincipal:a]>
>> at org.junit.Assert.fail(Assert.java:88)
>> at org.junit.Assert.failNotEquals(Assert.java:834)
>> at org.junit.Assert.assertEquals(Assert.java:118)
>> at org.junit.Assert.assertEquals(Assert.java:144)
>> at 
>>org.apache.jackrabbit.oak.spi.security.authentication.external.impl.princ
>>ipal.ExternalGroupPrincipalProviderTest.testGetGroupMembershipExternalUse
>>rInfiniteDepth(ExternalGroupPrincipalProviderTest.java:282)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at 
>>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
>>:57)
>> at 
>>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
>>mpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:606)
>> at 
>>org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMeth
>>od.java:50)
>> at 
>>org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallabl
>>e.java:12)
>> at 
>>org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod
>>.java:47)
>> at 
>>org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.
>>java:17)
>> at 
>>org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java
>>:26)
>> at 
>>org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:2
>>7)
>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>> at 
>>org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.
>>java:78)
>> at 
>>org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.
>>java:57)
>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>> at 
>>org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>
>I know that Angela has been looking at them, but it seems they are
>platform-specific (Windows...).
>
>Best regards, Julian
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.3

[Angela Schreiber]

hi davide

>Angela, could you set up a VM with windows.

already working on it... but it doesn't fail reliably
and it never fails, when i try to debug it.

angela

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.3

[Angela Schreiber]

hi julian

the problem was only with the tests and i didn't make any
changes in the actual code. so, my preference would be a)

angela

>So I believe Angela has managed to fix the issue (I can't repro it
>anymore in trunk).
>
>What does this mean for 1.5.3?
>
>a) Release anyway?
>
>b) Cancel release & release instead what we have now?
>
>c) Release anyway, but follow up with 1.5.4 shortly after?
>
>I have no preference here, as I have no insight how serious the actual
>problem was...
>
>Best regards, Julian

Re: [proposal] New oak:Resource nodetype as alternative to nt:resource

[Angela Schreiber]

Hi Chetan

On 15/07/16 09:47, "Chetan Mehrotra"  wrote:

>In most cases where code uses JcrUtils.putFile [1] it leads to
>creation of below content structure
>
>+ foo.jpg (nt:file)
>   + jcr:content (nt:resource)
>   - jcr:data
>
>Due to usage of nt:resource each nt:file node creates a entry in uuid
>index as nt:resource is referenceable [2]. So if a system has 1M
>nt:file nodes then we would have 1M entries in /oak:index/uuid as in
>most cases the files are created via [1] and hence all such files are
>referenceable
>
>The nodetype defn for nt:file [3] does not mandate that the
>requirement for jcr:content being nt:resource.
>
>So should we register a new oak:Resource nodetype which is same as
>nt:resource but not referenceable. This would be similar to
>oak:Unstructured.

+1

>
>Also what should we do for [1]. Should we provide an overloaded method
>which also accepts a nodetype for jcr:content node as it cannot use
>oak:Resource

Yes, we can do that.

Additionally or alternatively we could create a separate method (e.g.
putOakFile
or putOakResource or something explicitly mentioning the non-referenceable
nature of the content) that uses 'oak:Resource' and state that it requires
the
node type to be registered and will fail otherwise... that would be as easy
to use as 'putFile', which is IMO important.

Also I should explicitly refer to the oak-variant in the javadoc of
'putFile'
and explain the difference (and vice versa).

Kind regards
Angela


>
>Chetan Mehrotra
>[1] 
>https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src
>/main/java/org/apache/jackrabbit/commons/JcrUtils.java#L1062
>
>[2]
>[nt:resource] > mix:lastModified, mix:mimeType, mix:referenceable
>  primaryitem jcr:data
>   - jcr:data (binary) mandatory
>
>[3]
>
>[nt:file] > nt:hierarchyNode
>  primaryitem jcr:content
>  + jcr:content (nt:base) mandatory

Re: [proposal] New oak:Resource nodetype as alternative to nt:resource

[Angela Schreiber]

Hi Chetan

Yes... I am not too enthusiastic about changing the default implementation
and have it behave differently on let's say Oak 1.5.7 and previous versions
of Oak and Jackrabbit... that's IMHO breaking backwards compatibility of
an API that is potentially widely used and as such asking for nasty bugs.

We cannot expect that usage nt:resource and thus having a referenceable
node was always an (undesirable) side effect. There might be applications
that used the putFile method _because_ it created nt:resource and which
are relying on the jcr:content node to be referenceable.

So, I am fine either a variant of the simple putFile or the explicit way
as you proposed it... we may even end up with both... i don't have a strong
preference here. 

But changing putFile such as proposed by Justin is IMO not an option.

Kind regards
Angela



On 18/07/16 11:04, "Chetan Mehrotra"  wrote:

>Thanks for the feedback. Opened OAK-4567 to track the change
>
>
>On Mon, Jul 18, 2016 at 12:14 PM, Angela Schreiber 
>wrote:
>> Additionally or alternatively we could create a separate method (e.g.
>> putOakFile
>> or putOakResource or something explicitly mentioning the
>>non-referenceable
>> nature of the content) that uses 'oak:Resource' and state that it
>>requires
>> the
>> node type to be registered and will fail otherwise... that would be as
>>easy
>> to use as 'putFile', which is IMO important.
>
>@Angela - What about Justin's suggestion later around changing the
>current putFile implementation. Have it use oak:Resource is present
>otherwise fallback to nt:resource. This can lead to compatibility
>issue though as javadoc of putFile says it would use nt:resource
>
>Chetan Mehrotra

Re: Why is nt:resource referencable?

[Angela Schreiber]

Hi Bertrand

It used to be mix:referenceable in JSR170 (i.e. JCR 1.0) and we
kept it for backwards compatibility:

https://docs.adobe.com/content/docs/en/spec/jcr/1.0/6.7.22.9_nt_resource.ht
ml

So, adding oak:Resource sounds the right thing to do here.

Kind regards
Angela

On 20/07/16 11:19, "Bertrand Delacretaz"  wrote:

>Hi,
>
>OAK-4567 introduces a new oak:Resource nodetype as an alternative to
>nt:resource which has mix:referenceable.
>
>I understand the idea of making that node non-referencable for
>performance reasons, but why is nt:resource referenceable in the first
>place?
>
>builtin_nodetypes.cnd [1] has this definition
>
>  [nt:resource] > mix:mimeType, mix:lastModified, mix:referenceable
>primaryitem jcr:data
>- jcr:data (BINARY) mandatory
>
>but the JCR spec (JSR 283 10 August 2009) only has
>
>  [nt:resource] > mix:mimeType, mix:lastModified
>primaryitem jcr:data
>- jcr:data (BINARY) mandatory
>
>Introducing a new nodetype leaks into applications, removing the
>default mix:referenceable mixin on nt:resource would be much simpler
>(at the cost of a migration tool probably), and people can always
>re-add the mixin if they really need it.
>
>WDYT?
>
>-Bertrand
>
>[1] 
>http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/res
>ources/org/apache/jackrabbit/oak/plugins/nodetype/write/builtin_nodetypes.
>cnd

Re: Why is nt:resource referencable?

[Angela Schreiber]

Hi Chetan

I would not do that even if it was possible as it will break
every single application that relies on nt:resource to extend
from mix:referenceable... these applications would need to change
their code adding the mixin manually which may lead to follow
up issues, because adding a mixin by specification requires
different privileges than creating a node with just a name where
the primary type (in this case nt:resource) was the applicable node
type selected by the system.

I don't see anything wrong with introducing oak:Resource and let
application developers decide on which variant they prefer.

Kind regards
Angela

On 20/07/16 11:41, "Chetan Mehrotra"  wrote:

>On Wed, Jul 20, 2016 at 2:49 PM, Bertrand Delacretaz
> wrote:
>> but the JCR spec (JSR 283 10 August 2009) only has
>>
>>   [nt:resource] > mix:mimeType, mix:lastModified
>> primaryitem jcr:data
>> - jcr:data (BINARY) mandatory
>
>Thats interesting. Did not knew its not mandated in JCR 2.0. However
>looks like for backward compatibility we need to support it. See [1]
>where this was changed
>
>@Marcel - I did not understood JCR-2170 properly. But any chance we
>can switch to newer version of nt:resource and do not modify existing
>nodes and let the new definition effect/enforced only on new node.
>
>Chetan Mehrotra
>[1] 
>https://issues.apache.org/jira/browse/JCR-2170?focusedCommentId=12754941&p
>age=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comme
>nt-12754941

Re: Why is nt:resource referencable?

[Angela Schreiber]

Hi Chetan

That would be really troublesome for multiple reasons.

First of all nt:resource doesn't allow for residual properties as
it comes with defined set of property definitions. So, any attempt
to write a jcr:uuid property to such a node will fail.

Second, for other nodes that allow for residual properties (such as
e.g. oak:Unstructured), the declaring node type for such an jcr:uuid
property and thus the property definition itself would change
leading to very nasty problems, when you later try to add
mix:referenceable mixin type.

See e.g. OAK-2164, JCR-2779, OAK-2121, OAK-2246 (and maybe more).
So far our claim has always been that jcr:uuid is a reserved
property that must never be used for any other property than
the autocreated, mandatory, protected property defined by
mix:referenceable.

Really, I don't think that this would be feasible...
and just for the record: I am pretty sure that there was good
intention behind the change in nt-definition between JCR 1.0 and
JCR 2.0... but maybe not fully thought through when it comes to
backwards compatibility and I am sure that we would have changed
it when moving to Jackrabbit 2.x if that had worked.

Kind regards
Angela

On 20/07/16 12:53, "Chetan Mehrotra"  wrote:

>On Wed, Jul 20, 2016 at 4:04 PM, Marcel Reutegger 
>wrote:
>> Maybe we would keep the jcr:uuid property on the referenceable node and
>>add
>> the mixin?
>
>What if we do not add any mixin and just have jcr:uuid property
>present. The node would anyway be indexed so search would still work.
>Not sure if API semantics require that nodes lookedup by UUID have to
>be referenceable.
>
>For now I think oak:Resource is safest way. But just exploring other
>options if possible!
>
>
>Chetan Mehrotra

oak-upgrade fails

[Angela Schreiber]

hi oak-devs

the build fails in the oak-upgrade code.
anybody?

kind regards
angela

Re: unregister custom privilege

[Angela Schreiber]

Hi Marco

See answers inline below

On 13/08/16 13:25, "Marco Piovesana"  wrote:

>dear all,
>I'm working with custom privileges, I did register a custom privilege
>doing
>this:
>
>PrivilegeManager privilegeManager = ((JackrabbitWorkspace)
>session.getWorkspace()).getPrivilegeManager();
>Privilege privilege =
>privilegeManager.registerPrivilege("custom:mycustomprivilege",
>false, new String[0]);
>
>How can i delete it?

That's not possible in a regular JCR setup based on Oak.

>There's an automated way to specify all my custom
>privileges (like the file *.config for the custom node types)?

Currently this is only possible by registering them one after the other.
If there is common need for registering multiple privileges at once we
can add API extensions to the PrivilegeManager interface in jackrabbit-api.
But there is no *.config file support for custom node types either...
not sure what you are referring to. Maybe you have to elaborate on this.

Kind regards
Angela

>
>Marco.

Re: How to get principals from a session?

[Angela Schreiber]

Hi Rob

Obtaining the set of principals from the session is not possible
with the default implementation.

Maybe you can add some context explaining what you would need that
for?

Kind regards
Angela

On 10/10/16 15:50, "Robert Haycock"
 wrote:

>Hi,
>
>Version/branch - oak trunk.
>
>I have JAAS setup and I'm trying to get the principals. In Jackrabbit
>this was simple but proving somewhat illusive in Oak.
>
>I have a session and I can see SessionImpl -> sd (RepositoryImpl)->
>contentSession (ContentSessionImp) -> loginContext (JaasLoginContext) ->
>subject -> principals.
>
>But as they are all private members with no public getters I can't get to
>the principals. How do I?
>
>Thanks,
>Rob.

Re: How does having lot of ACL (for different principals) on a single node affect performance

[Angela Schreiber]

Hi Vikas

Here some input to the different topics|questions raised below.

On 24/10/16 17:01, "Vikas Saurabh"  wrote:

>Hi,
>
>In a project I'm working, we have a some personas which represent the
>kind of operations member of those personas are allowed to do over a
>given node.
>
>The most trivial idea was to have a
>synthetic-group-per-persona-per-such-node and add/remove members to
>these groups. This approach has obvious side-effects:
>* systems gets flooded with system-generated-groups thus requiring
>special UI for user/group management

Are you talking about real users/groups as defined by the Jackrabbit
user management or about simple principals as we discussed during the
last Oakathon? For the latter the UI is limited to crx-explorer which
is the only UI Adobe provides that exposes the principal management UI.

>* can potentially affect login performance - I haven't checked how
>OAK-3003 works.. maybe, it's a non-issue

Without knowing the exact details of your use-case: depending on how your
synthetic-groups are envisioned to work and whether or not this member
is really intended to be edited and managed through the CQ user management
UI, you may consider solving this with principal management rather than
user management... see above and also referring to the conversation
we had last time.

>* eerie feeling to require additional groups :)
>
>The other end of the spectrum is to provide explicit ACLs on the node
>per principal. It's ok for us to go this way... but we ended up with
>an open question on the subject the mail. Do we know how ACL
>evaluation performance behave wrt number-of-ACLs on a node - assuming
>ACLs-per-principal won't be a big number?

The access control content as stored with the individual nodes in ACLs
and ACEs is _not_ used for the evaluation at all. Permission evaluation
and thus performance of permission evaluation of the default authorization
model is purely defined by the performance of compiling effective
permissions from the data stored in the permission store at
/jcr:system/rep:permissionStore.

In other words: the permission evaluation is based on the following
pieces:

1. the set of principals as pushed to the subject upon authentication
2. permission-entries stored separately for each principal in the
perm-store
3. separation of the 2 types of principals as defined by java (Principal
and java.security.acl.Group)

Based on the original design goals we laid out for Oak promising that
flat hierarchies of non-ordered nodes is supported, I would not expect
issues with a huge amount of permission entries in the store for a single
principal.

On the other hand: access control entries as edited by the default
user facing access control management implementation are collected in
a list which be definition has an order. this is reflected by the
content structure storing ACEs as nodes below a policy node that is defined
to have orderable children. Since support for huge flat hierarchies
of _orderable_ nodes was a explicit non-goal of Oak, I would expect
to see limitations here when it comes to tens of thousands of ACEs
for a given single ACL. My take is: if a given application ends up with
tens of thousands of access control entries within a given list this
may either highlight design issues with the content modelling wrt
security or it may give us a hint that a different authorization model
might be more suited for that use-case.

>I was thinking of writing a benchmark to see but wanted to copy some
>closely related existing benchmark. It'd great if there are some
>pointers for this :).

There are some authorization related benchmarks and Alex Collignon
will provide some additional in the light of OAK-5025.

As far as login-performance is concerned there are quite some benchmarks
available for the different topics involved with authentication such as
e.g.
- GetGroupPrincipalsTest where you could verify OAK-3003
- in the authentication.external package benchmarks illustrating what the
  performance with the 'dynamic group membership' would look like compared
  to full sync intro the repositories user management
- membership related benchmarks
- pure login benchmarks for various types of principals

If you are looking for specific benchmarks or need help writing one,
let me know.

Hope that helps
angela

>
>Thanks,
>Vikas

Re: How does having lot of ACL (for different principals) on a single node affect performance

[Angela Schreiber]

hi vikas

the setup you describe below sounds pretty similar what alex and myself
discussed recent with consultants based on some customer requirements.

in particular the fact that you bake different permission relevant
attributes into the naming convention for a groups sounds pretty wrong
to me and doesn't seem like a good solution over time as the number
of content and roles evolve. and the permission set will get awfully
complicated with the default model given the fact that if you would
write it down in in words it would be most probably quite straight
forward.

if you wish we could take that offline and discuss it over all call
that needs less time writing up all the details... we might also see
at that point how much your setup is inline with what alexC and myself
recently discussed for that customer and how we agreed there to move
forward.

would that work for you?

kind regards
angela

On 09/11/16 11:17, "Vikas Saurabh"  wrote:

>Thanks Angela and Michael. Angela, I've replied to a few part inline
>below.
>
>>>The most trivial idea was to have a
>>>synthetic-group-per-persona-per-such-node and add/remove members to
>>>these groups. This approach has obvious side-effects:
>>>* systems gets flooded with system-generated-groups thus requiring
>>>special UI for user/group management
>>
>> Are you talking about real users/groups as defined by the Jackrabbit
>> user management or about simple principals as we discussed during the
>> last Oakathon? For the latter the UI is limited to crx-explorer which
>> is the only UI Adobe provides that exposes the principal management UI.
>>
>
>I meant groups via jackrabbit user management. I was leaning out of
>this option due to point#3 (eerie feeling)
>
>>>* can potentially affect login performance - I haven't checked how
>>>OAK-3003 works.. maybe, it's a non-issue
>>
>> Without knowing the exact details of your use-case: depending on how
>>your
>> synthetic-groups are envisioned to work and whether or not this member
>> is really intended to be edited and managed through the CQ user
>>management
>> UI, you may consider solving this with principal management rather than
>> user management... see above and also referring to the conversation
>> we had last time.
>>
>
>To elaborate a bit on use-case: consider 2 personas like ""
>and "". Where  (or ) is essentially a
>"synonym" of what type of privileges do s have (it might be
>more that read... it might be read on current node + some more privs
>for content-structure under it.
>All  need to have same type of access on the content.
>Similarly  have same perms. The group idea was to create
>"content-1-viewer" and "content-1-editor" group, give relevant access
>on "content-1" to these groups, and then make actual users member of
>these groups depending on if they are viewer or editor
>(there's another persona "author" who is stronger that editor in the
>sense that they are allowed to make others , , etc...
>I kept to 2 for simplification.
>
>>>The other end of the spectrum is to provide explicit ACLs on the node
>>>per principal. It's ok for us to go this way... but we ended up with
>>>an open question on the subject the mail. Do we know how ACL
>>>evaluation performance behave wrt number-of-ACLs on a node - assuming
>>>ACLs-per-principal won't be a big number?
>>
>> The access control content as stored with the individual nodes in ACLs
>> and ACEs is _not_ used for the evaluation at all. Permission evaluation
>> and thus performance of permission evaluation of the default
>>authorization
>> model is purely defined by the performance of compiling effective
>> permissions from the data stored in the permission store at
>> /jcr:system/rep:permissionStore.
>>
>> In other words: the permission evaluation is based on the following
>> pieces:
>>
>> 1. the set of principals as pushed to the subject upon authentication
>> 2. permission-entries stored separately for each principal in the
>> perm-store
>> 3. separation of the 2 types of principals as defined by java (Principal
>> and java.security.acl.Group)
>>
>> Based on the original design goals we laid out for Oak promising that
>> flat hierarchies of non-ordered nodes is supported, I would not expect
>> issues with a huge amount of permission entries in the store for a
>>single
>> principal.
>
>That's good to know :). So, unless we're talking about editing
>permissions on the node, it should be ok for having large number of
>ACL/Es.
>
>>
>> On the other hand: access control entries as edited by the default
>> user facing access control management implementation are collected in
>> a list which be definition has an order. this is reflected by the
>> content structure storing ACEs as nodes below a policy node that is
>>defined
>> to have orderable children. Since support for huge flat hierarchies
>> of _orderable_ nodes was a explicit non-goal of Oak, I would expect
>> to see limitations here when it comes to tens of thousands of ACEs
>> for a given single ACL.
>
>Good point. 

Link to Security Summit

[Angela Schreiber]

hi oak devs

as just promised on the oakathon call here the link to the wiki page
of the next security summit. this would be a good opportunity to
present and discuss security relevant topics such as e.g. the binary
stuff discussed today.

https://wiki.corp.adobe.com/display/WEM/AEM+Security+Summit+2017


apart from the (extended) security team we will have vincent berg as
an external security expert in basel for 2 week. so occupying one of
the slots to discuss new features has proven to be a very efficient
way to secure our product(s).

- really technical discussions
- no sales/marketing demo expected
- huge amount of expertise gathered in one room with different focus
- break guaranteed after 1-1.5 hours... no meeting marathon ;-)

just let alex collignon or me know if you wish to have a slot

kind regards
angela

Re: Oak 1.5.15 release plan

[Angela Schreiber]

Hi Davide

IMO the fix for OAK-5200 is straight forward:

1. revert changes made to DynamicSyncContext: it's here where the bug was
introduced.
   that should be doable today.

2. have a quick discussion on oak-dev on how to deal with the new,
exported class ExternalGroupRef
   which was introduced (and was already backported): this one would not
be used any
   more after 1) but removing it again would (afaik) lead to a major
version bump.
   i want to get more opinions on that, because i am not aware that we had
the problem 
   before (or missed/don't remember how we dealt with it).
   if we see that it's not doable or too cumbersome reverting this class,
we may decide
   to leave it... we might find it useful later on or end up deprecating
it for 1.8.
   but i want to have a conscious decision here and some broader agreement
from the team.

   - if we leave it -> changes in auth-ldap code base don't need to be
reverted
   - if we revert it -> changes in auth-ldap also would need to be reverted

Hope that helps
Angela

PS: as far as the original improvement is concerned that was the intention
of OAK-4930
(but which is not obvious from the subject, which is not correct), we need
to have a new 
Improvement ticket, where we can discuss the options... I want that kind
of improvements
to be properly tracked in jira (and ultimately in the documentation and
benchmarked) such 
that everyone can understand why a given change was made... i had a hard
time yesterday to 
understand what was the actual aim of OAK-4930 and it was just by
coincidence that I hours
later spotted the issue... just because I could not understand how I could
have mixed up 
ID and principal  name in the original code (and which turned out wasn't
the case).
   

On 01/12/16 12:15, "Davide Giannella"  wrote:

>Hello team,
>
>I'm planning to cut Oak 1.5.15 on Monday 5th December.
>
>If there are any objections please let me know. Otherwise I will
>re-schedule any non-resolved issue for the next iteration.
>
>Angela, Manfred, is https://issues.apache.org/jira/browse/OAK-5200
>really a blocker for 1.5.15? Or is it rather for 1.6? If it's for 1.5.15
>how long for the fix to get done?
>
>Thanks
>Davide
>
>

Re: Oak 1.5.15 release plan

[Angela Schreiber]

Hi Manfred

I don't see how you can 'keep it' for the LDAP case. Please create
new Improvement ticket, such that we can look for a proper solution.

What you actually wanted to do but which IMO got never explicitly
mentioned due to mixing implementation details with the generic
sync-stuff:

"Ability to resolve principal name from ExternalIdentityRef without IDP
roundtrip"

IMO such an improvement would make sense for all cases not just for the
LDAP
integration. But I want to have that done properly and without hacks
and relying on implementation details of one particular impl for the
generic 
code base.

Based on the experience we made here, I think it would make sense, to
get more reviews and feedback on changes for the mentioned modules.
Specially when API extensions are involved that are really cumbersome
to fix later on. In general I think this is a very good practise and
it may help spotting issues early in the cycle.

Kind regards
Angela


On 01/12/16 13:46, "Manfred Baedke"  wrote:

>Hi Davide, Angela,
>
>Note that this is not an issue with oak-auth-ldap, but rather with
>oak-auth-external.
>
>The ExternalIdentity implementation used by oak-auth-ldap uses the DN as
>both the id and the principal name, so it's working fine. Other
>implementations of the external auth mechanism may run into problems
>(btw: are other implementations known?).
>
>I'm going to revert the change now, but since the performance
>improvement was striking on customer site, I'd like to keep it for the
>LDAP case. Anyone feel free to give suggestions on the most elegant way
>to do this.
>
>Best regards,
>Manfred
>
>On 12/1/2016 12:52 PM, Angela Schreiber wrote:
>> Hi Davide
>>
>> IMO the fix for OAK-5200 is straight forward:
>>
>> 1. revert changes made to DynamicSyncContext: it's here where the bug
>>was
>> introduced.
>> that should be doable today.
>>
>> 2. have a quick discussion on oak-dev on how to deal with the new,
>> exported class ExternalGroupRef
>> which was introduced (and was already backported): this one would
>>not
>> be used any
>> more after 1) but removing it again would (afaik) lead to a major
>> version bump.
>> i want to get more opinions on that, because i am not aware that we
>>had
>> the problem
>> before (or missed/don't remember how we dealt with it).
>> if we see that it's not doable or too cumbersome reverting this
>>class,
>> we may decide
>> to leave it... we might find it useful later on or end up
>>deprecating
>> it for 1.8.
>> but i want to have a conscious decision here and some broader
>>agreement
>> from the team.
>>
>> - if we leave it -> changes in auth-ldap code base don't need to be
>> reverted
>> - if we revert it -> changes in auth-ldap also would need to be
>>reverted
>>
>> Hope that helps
>> Angela
>>
>> PS: as far as the original improvement is concerned that was the
>>intention
>> of OAK-4930
>> (but which is not obvious from the subject, which is not correct), we
>>need
>> to have a new
>> Improvement ticket, where we can discuss the options... I want that kind
>> of improvements
>> to be properly tracked in jira (and ultimately in the documentation and
>> benchmarked) such
>> that everyone can understand why a given change was made... i had a hard
>> time yesterday to
>> understand what was the actual aim of OAK-4930 and it was just by
>> coincidence that I hours
>> later spotted the issue... just because I could not understand how I
>>could
>> have mixed up
>> ID and principal  name in the original code (and which turned out wasn't
>> the case).
>> 
>>
>> On 01/12/16 12:15, "Davide Giannella"  wrote:
>>
>>> Hello team,
>>>
>>> I'm planning to cut Oak 1.5.15 on Monday 5th December.
>>>
>>> If there are any objections please let me know. Otherwise I will
>>> re-schedule any non-resolved issue for the next iteration.
>>>
>>> Angela, Manfred, is https://issues.apache.org/jira/browse/OAK-5200
>>> really a blocker for 1.5.15? Or is it rather for 1.6? If it's for
>>>1.5.15
>>> how long for the fix to get done?
>>>
>>> Thanks
>>> Davide
>>>
>>>
>

Re: OAK-5025

[Angela Schreiber]

Hi

I am quite reluctant to back port improvements as - according to my
knowledge - we originally had the policy to only back port critical bugs
or vulnerabilities. The recent issues we faced with back ports doesn't add
any confidence. IMHO people should upgrade to the more recent releases to
get improvements (or new features).

Kind regards
Angela

On 13/01/17 11:11, "Julian Reschke"  wrote:

>On 2017-01-12 18:35, Mark Vance wrote:
>> Hi,
>> If it is not too late, I would like to vote for this enhancement.
>> https://issues.apache.org/jira/browse/OAK-5025
>>
>> Could we have a discussion on including this in 1.2.23?
>>
>> Thanks,
>> Mark
>
>Well, first it would need to go into 1.4.
>
>Angela?
>
>Best regards, Julian
>

Review OAK-5623

[Angela Schreiber]

Hi 

I would appreciate if you could review OAK-5623 [1] aimed to verify line
coverage upon building the 3 security related modules outside of oak-core.
Since we already make use of the corresponding mvn plugin in the parent
pom.xml I decided to add the basics there and only enabled it for the
security modules.

Building oak including integration tests worked for me but changes to the
parent affect everyone and IMO require consensus.

Thanks
Angela


[1] https://issues.apache.org/jira/browse/OAK-5623

Re: oak-run, diet and new module

[Angela Schreiber]

hi davide

could you elaborate a bit on your proposal? from the names (oak-operations
and oak-development) it's not clear to me what code would go into which
module... also i am not sure about deleting oak-run. for the sake of
limiting impact (also when it comes to the backport you mention later on)
i would rather suggest to move out code that doesn't belong there and keep
stuff that more naturally fits into 'run': so, only one additional module
and no deletion.

as far as backporting to all branches is concerned: that's for sure not
feasible for the benchmarks i have been putting into oak-run when
introducing new features and improvements.

kind regards
angela

On 09/02/17 20:28, "Davide Giannella"  wrote:

>hello team,
>
>while having a bit of time I resumed the topic grouped in the epic
>https://issues.apache.org/jira/browse/OAK-5599.
>
>Part of the discussion we already had in the past 1 or two years is that
>oak-run is big and begin to be a challenge during releases and the fact
>that we could split development functionalities from production tooling
>would allow us to remove quite a bunch of libraries from the jar
>deployed on mvn for production tooling and will leave the development
>one not deployed.
>
>Main scratching I have now is: assuming we proceed what about backports?
>So i thought the following:
>
>- main goal: create oak-operations and oak-development modules.
>Eventaully delete oak-run.
>- backport these on all the branches. Up to what version? Can we blindly
>backport all of the stuff?
>- what are the differences nowadays in oak-run between branches?
>Repository construction? others?
>
>Thoughts?
>
>Cheers
>Davide

Re: Review OAK-5623

[Angela Schreiber]

Hi

Going to commit the proposed changes with the adjustment discussed in the
issue.
We can take it further in case it caused troubles with the windows builds.

Angela

On 09/02/17 17:16, "Angela Schreiber"  wrote:

>Hi 
>
>I would appreciate if you could review OAK-5623 [1] aimed to verify line
>coverage upon building the 3 security related modules outside of oak-core.
>Since we already make use of the corresponding mvn plugin in the parent
>pom.xml I decided to add the basics there and only enabled it for the
>security modules.
>
>Building oak including integration tests worked for me but changes to the
>parent affect everyone and IMO require consensus.
>
>Thanks
>Angela
>
>
>[1] https://issues.apache.org/jira/browse/OAK-5623
>

Re: Review OAK-5623

[Angela Schreiber]

hi

just for the record: this can be turned on for any other modules as well
by adding the following entries to the :


[...]

false
0.xx



all credits to marc pfaff who showed me an example and inspired me to
enforce this for the oak security modules.

kind regards
angela

On 14/02/17 15:27, "Angela Schreiber"  wrote:

>Hi
>
>Going to commit the proposed changes with the adjustment discussed in the
>issue.
>We can take it further in case it caused troubles with the windows builds.
>
>Angela
>
>On 09/02/17 17:16, "Angela Schreiber"  wrote:
>
>>Hi 
>>
>>I would appreciate if you could review OAK-5623 [1] aimed to verify line
>>coverage upon building the 3 security related modules outside of
>>oak-core.
>>Since we already make use of the corresponding mvn plugin in the parent
>>pom.xml I decided to add the basics there and only enabled it for the
>>security modules.
>>
>>Building oak including integration tests worked for me but changes to the
>>parent affect everyone and IMO require consensus.
>>
>>Thanks
>>Angela
>>
>>
>>[1] https://issues.apache.org/jira/browse/OAK-5623
>>
>

Merging OAK-5654 into 1.6.1

[Angela Schreiber]

hi 

i would like to merge the log-level changes applied for
https://issues.apache.org/jira/browse/OAK-5654 into 1.6.1.
don't see any risk associated but it might help avoid confusing caused by
unnecessary warning.

if nobody objects i would go ahead and merge it later today.

br
angela

Re: CommitEditors looking for specific child node like oak:index, rep:cugPolicy leads to lots of redundant remote calls

[Angela Schreiber]

hi

yes that mixin exists. but the CugValidatorProvider is performs additional
validation and doesn't allow for usage of the reserved names if the mixin
is not there... so we cannot limit the evaluation to nodes that have the
mixin type set (or inherited through super-type).
see http://jackrabbit.apache.org/oak/docs/security/authorization/cug.html
for details.

kind regards
angela

On 22/02/17 14:26, "Marcel Reutegger"  wrote:

>Hi,
>
>On 22/02/17 12:57, Chetan Mehrotra wrote:
>> One possible approach is to mark the parent with a specific hidden
>> property which has such a node upon addition. This would avoid the
>> negative lookup in case of updates
>
>Alternatively we could also mark the parent node with a mixin. This
>would be similar to nodes that can have a rep:policy child nodes. In
>that case the parent node is rep:AccessControllable.
>
>At least for rep:cugPolicy nodes this seems to be the case already. The
>node type registry of my Oak 1.6 repository says:
>
>[rep:CugMixin]
>   mixin
>   + rep:cugPolicy (rep:CugPolicy) protected ignore
>
>[rep:CugPolicy] > rep:Policy
>   - rep:principalNames (string) mandatory protected multiple ignore
>
>
>Regards
>  Marcel

Merging OAK-5784 into 1.6.1

[Angela Schreiber]

hi oak-devs

i would like to merge another improvement into the 1.6.1 branch:
https://issues.apache.org/jira/browse/OAK-5784

in addition to additional tests i run the AceCreationTest benchmark and
attached the results to the issue.
however, having some extra pair of eyes would be appreciated in order to
limit the risk of regressions.

thanks
angela

Re: Merging OAK-5784 into 1.6.1

[Angela Schreiber]

Hi Chetan

Thanks a lot for your input!
In fact I looked at the PropertyStateValue implementation and spotted the
usage of the internal string representation. However, for the Restriction
case I could not come up with a use case that would involve a binary
value. The supported restrictions we are shipping are all of type STRING
or NAME. As far as custom implementations are concerned I doubt that
BINARY would make sense... but who knows... maybe it would be worth
explicitly stating in the documentation at
http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.ht
ml#pluggability that

a) performance must be taken into consideration when writing custom impls
b) the base impl of the Restriction interface relies on
PropertyStateValue.hashCode and custom implementations may need to adjust
that _if_ they contain binaries... ok... i don't think that would be
sensible... but who knows :-)

as far as PropertyState.hashCode is concerned: i vaguely remember that we
discussed that in the early days of Oak and decided that there is no need
for including the value because a given Tree object will never have
multiple properties with the same name and thus decided to just use the
name and type for performance reasons.

as far as PropertyStateValue is concerned: while working on the
improvement i struggled again with the fact that the implementation of
this oak-api interface is located in spi.query package that looks
pretty troublesome to me from a design point of view. maybe this is
another indication that we should think about having an implementation
with plugins.memory and deal with the binary topic there.

wdyt?
kind regards
angela

On 24/02/17 10:39, "Chetan Mehrotra"  wrote:

>Changes look fine however one aspect might cause issue
>
>RestrictionImpl#hashCode -> PropertyValues#hashCode ->
>PropertyStateValue#hashCode
>
>
>private String getInternalString() {
>StringBuilder sb = new StringBuilder();
>Iterator iterator = getValue(Type.STRINGS).iterator();
>while (iterator.hasNext()) {
>sb.append(iterator.next());
>if (iterator.hasNext()) {
>sb.append(",");
>}
>}
>return sb.toString();
>}
>
>@Override
>public int hashCode() {
>return getType().tag() ^ getInternalString().hashCode();
>}
>
>
>Here it tries to get value as STRINGS which leads to
>PropertyState#getValue(Type.STRINGS) which would lead to a Binary
>getting coerced to String in Conversions#convert(Blob) which would
>lead to load of whole binary. Now I am not sure if PropertyState in
>RestrictionImpl is applicable for Binary property also
>
>Probably PropertyStateValue#hashCode should take care of Binary
>properties and thats why PropertyState#hashCode does not take into
>account the value
>Chetan Mehrotra
>
>
>On Fri, Feb 24, 2017 at 2:34 PM, Angela Schreiber 
>wrote:
>> hi oak-devs
>>
>> i would like to merge another improvement into the 1.6.1 branch:
>> https://issues.apache.org/jira/browse/OAK-5784
>>
>> in addition to additional tests i run the AceCreationTest benchmark and
>> attached the results to the issue.
>> however, having some extra pair of eyes would be appreciated in order to
>> limit the risk of regressions.
>>
>> thanks
>> angela
>>
>>

Re: Merging OAK-5784 into 1.6.1

[Angela Schreiber]

Hi Chetan

Created OAK-5838 <https://issues.apache.org/jira/browse/OAK-5838> to keep
track of the topics discussed here.

Kind regards
Angela

On 24/02/17 11:56, "Chetan Mehrotra"  wrote:

>On Fri, Feb 24, 2017 at 4:10 PM, Angela Schreiber 
>wrote:
>> maybe this is
>> another indication that we should think about having an implementation
>> with plugins.memory and deal with the binary topic there.
>
>+1
>
>Then we can go with current fix (and also merge to 1.6) and later
>backport the change to 1.6 branch
>
>
>Chetan Mehrotra

Re: Merging OAK-5784 into 1.6.1

[Angela Schreiber]

updated documentation with the 2 points mentioned below at revision
1785128.

On 24/02/17 11:40, "Angela Schreiber"  wrote:

>Hi Chetan
>
>Thanks a lot for your input!
>In fact I looked at the PropertyStateValue implementation and spotted the
>usage of the internal string representation. However, for the Restriction
>case I could not come up with a use case that would involve a binary
>value. The supported restrictions we are shipping are all of type STRING
>or NAME. As far as custom implementations are concerned I doubt that
>BINARY would make sense... but who knows... maybe it would be worth
>explicitly stating in the documentation at
>http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.h
>t
>ml#pluggability that
>
>a) performance must be taken into consideration when writing custom impls
>b) the base impl of the Restriction interface relies on
>PropertyStateValue.hashCode and custom implementations may need to adjust
>that _if_ they contain binaries... ok... i don't think that would be
>sensible... but who knows :-)
>
>as far as PropertyState.hashCode is concerned: i vaguely remember that we
>discussed that in the early days of Oak and decided that there is no need
>for including the value because a given Tree object will never have
>multiple properties with the same name and thus decided to just use the
>name and type for performance reasons.
>
>as far as PropertyStateValue is concerned: while working on the
>improvement i struggled again with the fact that the implementation of
>this oak-api interface is located in spi.query package that looks
>pretty troublesome to me from a design point of view. maybe this is
>another indication that we should think about having an implementation
>with plugins.memory and deal with the binary topic there.
>
>wdyt?
>kind regards
>angela
>
>On 24/02/17 10:39, "Chetan Mehrotra"  wrote:
>
>>Changes look fine however one aspect might cause issue
>>
>>RestrictionImpl#hashCode -> PropertyValues#hashCode ->
>>PropertyStateValue#hashCode
>>
>>
>>private String getInternalString() {
>>StringBuilder sb = new StringBuilder();
>>Iterator iterator = getValue(Type.STRINGS).iterator();
>>while (iterator.hasNext()) {
>>sb.append(iterator.next());
>>if (iterator.hasNext()) {
>>sb.append(",");
>>}
>>}
>>return sb.toString();
>>}
>>
>>@Override
>>public int hashCode() {
>>return getType().tag() ^ getInternalString().hashCode();
>>}
>>
>>
>>Here it tries to get value as STRINGS which leads to
>>PropertyState#getValue(Type.STRINGS) which would lead to a Binary
>>getting coerced to String in Conversions#convert(Blob) which would
>>lead to load of whole binary. Now I am not sure if PropertyState in
>>RestrictionImpl is applicable for Binary property also
>>
>>Probably PropertyStateValue#hashCode should take care of Binary
>>properties and thats why PropertyState#hashCode does not take into
>>account the value
>>Chetan Mehrotra
>>
>>
>>On Fri, Feb 24, 2017 at 2:34 PM, Angela Schreiber 
>>wrote:
>>> hi oak-devs
>>>
>>> i would like to merge another improvement into the 1.6.1 branch:
>>> https://issues.apache.org/jira/browse/OAK-5784
>>>
>>> in addition to additional tests i run the AceCreationTest benchmark and
>>> attached the results to the issue.
>>> however, having some extra pair of eyes would be appreciated in order
>>>to
>>> limit the risk of regressions.
>>>
>>> thanks
>>> angela
>>>
>>>
>

Re: Merge policy for the 1.6 branch

[Angela Schreiber]

sounds like a plan
angela

On 14/03/17 11:59, "Michael Dürig"  wrote:

>
>Hi,
>
>Following up on Davide's release plan for Oak 1.6 [1] we should define a
>merge policy for the 1.6 branch. I would suggest to be a bit more
>conservative here than we have been in the past and ask for reviews of
>backports. That is, announce candidates on @oak-dev mentioning the issue
>reference, potential risks, mitigations, etc. I don't think we need to
>block the actual backport being performed on the outcome of the review
>as in the worst case changes can always be reverted. The main aim of the
>announcement should be to increase visibility of the backports and
>ensure they are eventually reviewed.
>
>In short, announce your backport on @oak-dev and ask for review. If
>confident enough that the review will pass anyway, go ahead but be
>prepared to revert.
>
>I think this is what we informally did so far already but wanted to
>state this a bit more explicitly.
>
>WDYT?
>
>Michael
>
>
>
>[1] 
>https://lists.apache.org/thread.html/e5e71b61de9612d7cac195cbe948e8bdca58e
>e38ee16e7f124ea742c@%3Coak-dev.jackrabbit.apache.org%3E

Re: Merge policy for the 1.6 branch

[Angela Schreiber]

hi tommaso

given some issues faced with backports in the past, i would wish this to
be 
persistent and not just time boxed.

kind regards
angela


On 14/03/17 12:07, "Tommaso Teofili"  wrote:

>I have one concern: is such a backport policy meant to be time boxed (e.g.
>keep it for first N 1.6.x releases)?
>I am asking this because I'm wondering if we want to establish this policy
>for all backports (1.4, 1.2, 1.0 branches too), or alternatively we aim to
>be a bit conservative in the first months of a 1.x release and move back
>to
>a less strict merge policy for backports afterwards.
>
>Regards,
>Tommaso
>
>Il giorno mar 14 mar 2017 alle ore 11:59 Michael Dürig
>
>ha scritto:
>
>>
>> Hi,
>>
>> Following up on Davide's release plan for Oak 1.6 [1] we should define a
>> merge policy for the 1.6 branch. I would suggest to be a bit more
>> conservative here than we have been in the past and ask for reviews of
>> backports. That is, announce candidates on @oak-dev mentioning the issue
>> reference, potential risks, mitigations, etc. I don't think we need to
>> block the actual backport being performed on the outcome of the review
>> as in the worst case changes can always be reverted. The main aim of the
>> announcement should be to increase visibility of the backports and
>> ensure they are eventually reviewed.
>>
>> In short, announce your backport on @oak-dev and ask for review. If
>> confident enough that the review will pass anyway, go ahead but be
>> prepared to revert.
>>
>> I think this is what we informally did so far already but wanted to
>> state this a bit more explicitly.
>>
>> WDYT?
>>
>> Michael
>>
>>
>>
>> [1]
>>
>> 
>>https://lists.apache.org/thread.html/e5e71b61de9612d7cac195cbe948e8bdca58
>>ee38ee16e7f124ea742c@%3Coak-dev.jackrabbit.apache.org%3E
>>

Re: Merge policy for the 1.6 branch

[Angela Schreiber]

Hi Julian

Unfortunately we had issues more than once and they are not limited to
indices. I distinctly remember troubles with semantic versioning, severe
bugs that were back ported without anybody looking at the code,
troublesome API...

Therefore I don't agree that sending a mail to the list and inviting
others to review changes is a waste of time or too much overhead.

Kind regards
Angela



On 14/03/17 13:19, "Julian Reschke"  wrote:

>On 2017-03-14 12:54, Julian Reschke wrote:
>> On 2017-03-14 11:59, Michael Dürig wrote:
>>>
>>> Hi,
>>>
>>> Following up on Davide's release plan for Oak 1.6 [1] we should define
>>>a
>>> merge policy for the 1.6 branch. I would suggest to be a bit more
>>> conservative here than we have been in the past and ask for reviews of
>>> backports. That is, announce candidates on @oak-dev mentioning the
>>>issue
>>> reference, potential risks, mitigations, etc. I don't think we need to
>>> block the actual backport being performed on the outcome of the review
>>> as in the worst case changes can always be reverted. The main aim of
>>>the
>>> announcement should be to increase visibility of the backports and
>>> ensure they are eventually reviewed.
>>> ...
>>
>> That sounds like a lot of overhead to me.
>>
>> What actual problem are we solving with this?
>>
>> Best regards, Julian
>
>I guess I need to expand on this.
>
>AFAICT, this has been triggered by one specific case where we backported
>something without considering the impact on existing deployments (here:
>creation of a new index that might cause the update to take a long time
>on big repositories).
>
>(Or am I missing something here...?)
>
>Contrast with that with the tons of backports we've been doing, yes,
>carefully, without such problems.
>
>Best regards, Julian
>

Re: Merge policy for the 1.6 branch

[Angela Schreiber]

Hi Davide

>From what I understood, Michaels proposal would not cause a stalling
backport:

{quote}
I don't think we need to
block the actual backport being performed on the outcome of the review
as in the worst case changes can always be reverted. The main aim of the
announcement should be to increase visibility of the backports and
ensure they are eventually reviewed.
{quote}

And later on:

{quote}
In short, announce your backport on @oak-dev and ask for review. If
confident enough that the review will pass anyway, go ahead but be
prepared to revert.
{quote}


My interpretation of this is as follows:

1.  I send out a notification before merging changes
2a. I think review should pass anyway -> go ahead and merge
2b. Otherwise: give others some time to look at it before merging,
depending on complexity, availability etc.
3.  Optional: In case of review failure after the fact -> revert again

With 3 we don't limit ourselves to perform the review in a fix time frame,
which might not be feasible.
Wdyt?

Kind regards

Angela

On 16/03/17 09:53, "Davide Giannella"  wrote:

>On 14/03/2017 10:59, Michael Dürig wrote:
>>
>> In short, announce your backport on @oak-dev and ask for review. If
>> confident enough that the review will pass anyway, go ahead but be
>> prepared to revert.
>
>+1 if we time box it for each backport. For example 3 days or whatever.
>Something like we do for releases. This is to prevent a backport to be
>stalling for too long. We may even define a vote policy like for
>releases but to be taken on the issue itself rather than here in the list.
>
>Davide
>
>

Re: New module oak-blob-cloud-azure?

[Angela Schreiber]

Hi Amit

In the light of discussions we had recently wrt modularisation, I would
also prefer to keep the new oak-blob-cloud-azure implementation in a
separate module.

Kind regards
Angela

On 15/03/17 10:29, "Amit Jain"  wrote:

>Hi Team,
>
>There is a new contribution for azure blob storage support - OAK-4933.
>This introduces a new module oak-blob-cloud-azure. This certainly seems to
>be the right approach from a separation and deployment standpoint. But in
>terms of code the module may only contain a few classes and also in future
>if we introduce (on my horizon) support for jclouds we could unify all
>under one module.
>
>What is the correct thing to do here?
>
>Thanks
>Amit

Re: oak-benchmarks and oak-run

[Angela Schreiber]

Hi Davide

Just had a first look: there are some scripts inside oak-run that can be
used to run benchmarks (which I actually do regularly). those are missing
in your fork oak-benchmarks module. Please make sure you move them as
well... i will also add this to the issue.

Thanks
Angela

On 22/03/17 16:18, "Davide Giannella"  wrote:

>Hello Team,
>
>as was discussed on OAK-3134[0], as part of [1] I'm going through the
>effort of moving the benchmarks we have in oak-run into their own
>module. This should allow us to then remove the dependencies from
>oak-run that by the investigation making the size of the module big.
>
>(0)
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.ap
>ache.org%2Fjira%2Fbrowse%2FOAK-3134%3FfocusedCommentId%3D15867631%26page%3
>Dcom.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel%23comm
>ent-15867631&data=02%7C01%7C%7Ce3dc16d7d89e413b7f7e08d47136aa01%7Cfa7b1b5a
>7b34438794aed2c178decee1%7C0%7C0%7C636257926970776627&sdata=y1Vu92RlszXj1y
>geXQJ68jPuL22QmbfVSzNRtFMq5wY%3D&reserved=0
>(1) 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.ap
>ache.org%2Fjira%2Fbrowse%2FOAK-3342&data=02%7C01%7C%7Ce3dc16d7d89e413b7f7e
>08d47136aa01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6362579269707866
>35&sdata=TM7QP3bhEhsJTxm2c7A3cNjKeqq%2FBduEtvrUdf%2FIy4Y%3D&reserved=0
>
>It resulted in quite refactoring of things around and before I actually
>produce a final patch for review and therefore I will have seen the
>oak-run size to drop, I'm kindly asking if you could start having a look
>at the work I've been doing [2] and provide feedbacks or questions if
>needed. Even on the ticket itself[1].
>
>(2)
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>m%2Fdavidegiannella%2Fjackrabbit-oak%2Fcommits%2Foak-benchmarks%3Fauthor%3
>Ddavidegiannella&data=02%7C01%7C%7Ce3dc16d7d89e413b7f7e08d47136aa01%7Cfa7b
>1b5a7b34438794aed2c178decee1%7C0%7C0%7C636257926970786635&sdata=YmABzxRXmB
>4C6eCnFnVyU8ygqJ%2BiVVhsaq9lmNpJka8%3D&reserved=0
>
>Cheers
>Davide
>
>

Re: Discrepancy between addAccessControlEntry and clear on versioned node

[Angela Schreiber]

hi marco

On 23/03/17 09:08, "Marco Piovesana"  wrote:

>Hi all, I was trying to change the permissions on a *versioned* node and i
>found two things that I don't quite understand:
>1) If i try to do an AccessControlUtils.addAccessControlEntry(...) i got
>an
>error if the node in not checked-out (and this seems consistent with what
>written on JCR-1639
>pache.org%2Fjira%2Fbrowse%2FJCR-1639&data=02%7C01%7C%7C01fba7b52c3d4f6e5b1
>408d471c6bde3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636258545789584
>278&sdata=Q3h1IR0CUjcHWF87kf2YGCrzIHlhO7Gve0F44w6QRPg%3D&reserved=0>).

afaik this is covered by the "VersionEditor" that asserts that versionable
nodes are checked-out when changes occur.

>However I can do an AccessControlUtils.clear(...) without any error. Why?

looking at the "VersionEditor" class it seems that the check is only
performed for the following operations:
- propertyAdded(PropertyState)
- propertyChanged(PropertyState, PropertyState)
- propertyDeleted(PropertyState)

however not for
- childNodeAdded(String name, NodeState after)
- childNodeRemoved(String name, NodeState after)


since i am not the author of that code, i don't know the reason for
this... would have expected the same check to be performed there.

>Aren't they both changing the ACL?

yes... are you calling save and thus make sure you trigger the
'VersionEditor'?
if you do, my guess would be that it's may not trigger the
checkin-state-verifying methods if the whole subtree is removed... but
that's just a wild guess... i didn't verify if that was really the
case that might be a bug in the versioning code.

>
>2) When I do AccessControlUtils.addAccessControlEntry(...) the error that
>i
>receive is: *OakVersion0001: Cannot add property jcr:mixinTypes on checked
>in node*. Why a change on the ACL should change the *jcr:mixinTypes*? My
>node was already versionable.

the utility method will create a new policy node (if not yet present)
which in the default implementation includes adding a mixin type to the
access controlled node... but it's not really relevant here... if it
wasn't for the mixin type it would fail for some other property being
added. a checked-in node is immutable which includes any modifications
related to access control management.

>
>One last question: if I want to change the permissions without having to
>check-out the node what I have to do? (I can do that by setting the
>*jcr:mixinTypes* to *IGNORE* but i don't think is the right way... or
>not?)

you can't change the access control content associated with a checked-in
node. you have to check it out before making any modifications.

regarding the missing OakVersion exception wrt removal of nodes, may i
kindly ask you to verify if you actually persist the changes? if you do
and no exception is raised that might highlight an issue in the versioning.

kind regards
angela

>
>
>Marco.

Re: Documenting enhancements done in Oak 1.6

[Angela Schreiber]

hi chetan

wouldn't it make more sense to generated list directly from JIRA? after
all that's exactly i would do to make sure i have a comprehensive list of
improvements and new features i was working on between oak 1.4 and 1.6.

kind regards
angela


On 23/03/17 15:15, "Chetan Mehrotra"  wrote:

>Hi Team,
>
>As part of OAK-5976 I am trying to collect topics around various
>enhancements done in Oak 1.6 release which we should document and make
>end user aware of them and take benefit of.
>
>For now I have covered various topics in Indexing, Document NodeStore
>new features, Observation etc.
>
>Kindly create subtask under this for any new feature/enhancement which
>you can remember.
>
>Once this is done I would like to link to those new changes from the
>main site page!
>
>Chetan Mehrotra

Re: Documenting enhancements done in Oak 1.6

[Angela Schreiber]

and maybe i have to add: the things i have been working on should already
be included in the documentation because i try to do that before i resolve
the issue. 

so my comment refers to what i would expect to be linked on the main...
not sure how your suggestion below would be covered by stuff that is
already documented...

angela

On 23/03/17 15:40, "Angela Schreiber"  wrote:

>hi chetan
>
>wouldn't it make more sense to generated list directly from JIRA? after
>all that's exactly i would do to make sure i have a comprehensive list of
>improvements and new features i was working on between oak 1.4 and 1.6.
>
>kind regards
>angela
>
>
>On 23/03/17 15:15, "Chetan Mehrotra"  wrote:
>
>>Hi Team,
>>
>>As part of OAK-5976 I am trying to collect topics around various
>>enhancements done in Oak 1.6 release which we should document and make
>>end user aware of them and take benefit of.
>>
>>For now I have covered various topics in Indexing, Document NodeStore
>>new features, Observation etc.
>>
>>Kindly create subtask under this for any new feature/enhancement which
>>you can remember.
>>
>>Once this is done I would like to link to those new changes from the
>>main site page!
>>
>>Chetan Mehrotra
>

Re: modify aggregated privilege

[Angela Schreiber]

hi marco

no, that's not possible.

kind regards
angela

On 23/03/17 17:47, "Marco Piovesana"  wrote:

>Hi all,
>I have defined a custom aggregated privilege defined like this:
>
>PrivilegeManager privilegeManager = ((JackrabbitWorkspace)
>session.getWorkspace()).getPrivilegeManager();
>Privilege privilege =
>privilegeManager.registerPrivilege("custom:myAggregated",
>false, new String[]{Privilege.JCR_READ,
>Privilege.JCR_READ_ACCESS_CONTROL});
>
>now i need to modify its definition (change the list of
>"declaredAggregateNames") but I can't find a way to do it. Is it possible
>to unregister it or modify its definition after it has been registered?
>
>Marco.