Intent to backport OAK-7356

Hi I would like to backport https://issues.apache.org/jira/browse/OAK-7356. Please let me know if you have any concern/objection. Kind regards Angela

Re: Oak related question

Hi This mailing list the right channel to post questions regarding Oak. Regards Angela On 16/03/18 08:19, "Kalach, Dmitry" wrote: >Hi > >We're using Jackrabbit Oak in our production. >And I have a question about how it works. Unfortunately, I've failed to >find any

Re: change node ownership

s wrong) that the user that >created a node would have had complete control on it (and not just the >permissions explicitly granted to him). That's why my question... thanks >again for the clarification. > >Marco. > > >On Wed, Feb 14, 2018 at 9:47 AM Angela Schreiber >

Re: change node ownership

Hi Marco It depends a bit on how you originally setup the 'ownership' in the first place. - if you have granted permissions to userA _on_ that very node, you can simply remove the entries and create new ones for the new owner. - if you have granted permissions to userA on a _parent_ node you can

identify abandoned oak modules

hi oak devs looking at the list of modules we have in oak/trunk i get the impression that some are not actively worked on or maintained. would it make sense or be possible to retire some of the modules that were originally started for productive usage and have been abandoned in the mean time?

Re: [m12n] Module oak-spi-core defines no export versions

s and only version those which are >meant to be used by users outside of Oak modules >Chetan Mehrotra > > >On Tue, Nov 14, 2017 at 11:00 PM, Angela Schreiber ><anch...@adobe.com.invalid> wrote: >> Hi Chetan >> >> Well... I would have excepted that one goal

Re: [m12n] Module oak-commons defines no export versions

Hi Oak Devs The same applies for oak-commons: all packages are exported and ignored by the baseline plugin in oak-parent. I created OAK-6945 <https://issues.apache.org/jira/browse/OAK-6945> to cover that. Kind regards Angela On 14/11/17 17:35, "Angela Schreiber" <anch..

Re: [m12n] Module oak-spi-core defines no export versions

tside of >Oak codebase would be using? As once we version it we cannot change in >backward incompatible way easily >Chetan Mehrotra > > >On Tue, Nov 14, 2017 at 10:05 PM, Angela Schreiber ><anch...@adobe.com.invalid> wrote: >> Hi Robert >> >> Ok... I will

Re: [m12n] Module oak-spi-core defines no export versions

Hi Robert Ok... I will add 1.0.0 and go ahead tomorrow unless someone objects. Kind regards Angela On 14/11/17 17:23, "Robert Munteanu" <romb...@apache.org> wrote: >On Tue, 2017-11-14 at 13:51 +0000, Angela Schreiber wrote: >> Any preference wrt the initial versi

[m12n] Module oak-spi-core defines no export versions

Hi Devs Looking at OAK-3919 I noticed that most packages in the new _core-spi_ module still don't have export versions properly handled. I guess this is an oversight that we missed during the modularisation. Unless someone objects I would go ahead

Re: Oak modularisation unstable roadmap ?

ather than as a wild contributed patch from someone outside the team who doesn't really understand how Oak works. Best Regards Ian On 17 October 2017 at 18:14, Angela Schreiber <anch...@adobe.com<mailto:anch...@adobe.com>> wrote: Hi Ian Would you mind sharing your thoughts and why

Re: Oak modularisation unstable roadmap ?

release I know hasn't been tested with integration tests. I have asked those who are waiting for this feature if they can wait till Oak 2.0 is released. Best Regards Ian On 13 October 2017 at 17:09, Angela Schreiber <anch...@adobe.com<mailto:anch...@adobe.com>> wrote: I sha

Re: Consider making Oak 1.8 an Oak 2.0

x. Will it be the case ? Thanks, Andrei [1] http://semver.org/ On Oct 17, 2017, at 10:13 AM, Angela Schreiber <anch...@adobe.com.INVALID<mailto:anch...@adobe.com.INVALID>> wrote: Hi Davide Sure... I already started doing so and there is a dedicated JIRA ticket for that matte

Re: Oak modularisation unstable roadmap ?

I share Julians concerns. In a private conversation Marcel suggested to reconsider placing the new API into oak-api and put it to Jackrabbit API instead. If there is really no Oak dependency in there that would make a lot of sense to me. In particular since the Sling community used to be quite

Consider making Oak 1.8 an Oak 2.0

hi given the fact that the m12n topic is quite an effort and has major consequences for oak, i would like to propose that we discuss the option of making the next stable release from trunk a 2.0 instead of just a next 1.8. imho it would better reflect the changes if we compare it to a minor step

Re: Oak modularisation unstable roadmap ?

hi ian q1: i'd say no. but might require more rounds as we complete the m12n. q2: yes. that's my understanding of the discussed we had just this week. one additional thing i would like to bring up: IMHO we should consider making this an 2.0 release given the fact that the m12n task is quite an

Re: OAK-6575 - A word of caution

Hi Davide Oh... I guess there is a misunderstanding... don't think anybody wants to make the release process more difficult. Taking our threat model into consideration (once we have one) cannot be the responsibility of the person that cuts the release; at that point it's too late anyway. What we

Re: OAK-6575 - A word of caution

Hi Ian On 13/09/17 23:34, "Ian Boston" <i...@tfd.co.uk> wrote: >Hi Angela, > >On 13 September 2017 at 06:50, Angela Schreiber ><anch...@adobe.com.invalid> >wrote: > >> Hi Ian >> >> The new proposal looks a lot better to me. >>

Re: OAK-6575 - A word of caution

Hi Ian The new proposal looks a lot better to me. The only concern from a security perspective I could come up with is the one we expressed already with the very first proposal (see initial word of caution mail sent by Francesco): applications built on top of Oak can up to now be sure that all

Re: frozen node modifications

hi marco i think your problem is 2-folded: 1. you need modifications to your content structure to reflect the evolution of your app 2. you intend to adjust existing versions of the nodes with that node type As far as 1 is concerned there are different ways to achieve this. from my point of view

Re: failure building oak-upgrade

hi tomek confirming that the issue is gone. thanks a lot angela On 29/05/17 20:45, "Tomek Rekawek" wrote: >Hi, > >regression fixed, sorry for that. > >Regards, >Tomek > >-- >Tomek Rękawek | Adobe Research | www.adobe.com >reka...@adobe.com > >> On 29 May 2017, at

Re: Enforcing minimal test coverage

Hi Bertrand Thanks for the pointer. As I explained in my reply to Michael it's not about the absolute numbers but rather about getting early feedback during development. As far as I am concerned I only run the ITs if I know (or suspect) a change to have a huge impact otherwise it just takes

Re: Enforcing minimal test coverage

at the code with a different mindset. kind regards angela On 11/05/17 14:46, "Michael Dürig" <mdue...@apache.org> wrote: > > >On 11.05.17 12:05, Angela Schreiber wrote: >> - oak-segment-tar: 0.65 > >I guess this only includes the coverage from running unit tests an

Re: Enforcing minimal test coverage

in oak-core-spi kind regards angela On 11/05/17 12:49, "Julian Reschke" <julian.resc...@gmx.de> wrote: >On 2017-05-11 12:05, Angela Schreiber wrote: >> hi oak-devs >> >> as a follow up to http://markmail.org/message/rzbqwwx3lilshct6 i would >> l

Enforcing minimal test coverage

hi oak-devs as a follow up to http://markmail.org/message/rzbqwwx3lilshct6 i would like to suggest that we enforce minimal test coverage not only with security modules but also for other oak code that is used in production. i gave it a try and identified those modules that already have a

Re: [m12n] parent pom reference

thanks a lot! On 26/04/17 15:01, "Marcel Reutegger" <mreut...@adobe.com> wrote: >On 26/04/17 14:37, Angela Schreiber wrote: >> for the modules created during the m12n effort that's an oversight >> can you create an issue? > >See OAK-6133. I will change it accordingly. > >Regards > Marcel

Re: [m12n] parent pom reference

hi marcel for the modules created during the m12n effort that's an oversight can you create an issue? angela On 26/04/17 14:13, "Marcel Reutegger" wrote: >Hi, > >I noticed that the new modules have a parent pom reference like this: > >jackrabbit-oak >

Re: [m12n] Location of InitialContent

s may >just be wishful thinking... > >Regards >Julian > > >On Thu, Apr 20, 2017 at 10:07 AM, Angela Schreiber <anch...@adobe.com> >wrote: >> hi >> >> the original intention of the 'InitialContent' was just to registers >> built-in JCR node types

[m12n] Location of InitialContent

hi the original intention of the 'InitialContent' was just to registers built-in JCR node types, which explains it's location in org.apache.jackrabbit.oak.plugins.nodetype.write in the mean time it has a evolved to container for all kind of initial content required for a JCR repository:

Re: [m12n] A new home for ApproximateCounter, NodeUtil and TreeUtil?

than just for the indexing. the other one probably needs some more effort. angela On 19/04/17 17:45, "Robert Munteanu" <romb...@apache.org> wrote: >On Tue, 2017-04-18 at 06:21 +0000, Angela Schreiber wrote: >> Hi Robert >> >> While NodeUtil and TreeUtil woul

Re: [m12] Effort to Improve Modularisation of Oak

.@apache.org> wrote: > > >On 19.04.17 16:26, Angela Schreiber wrote: >>> I'm actually reluctant about 1) and 2) as renaming established modules >>> have quite a ripple effect. As with 3) we already have sub-modules in >>> one place we should probably start a disc

Re: [m12] Effort to Improve Modularisation of Oak

ela >> >> On 18/04/17 08:57, "Michael Dürig" <mdue...@apache.org> wrote: >> >>> >>> >>> On 13.04.17 15:52, Angela Schreiber wrote: >>>> {quote} >>>> I would suggest to go with a naming scheme that reflects how modul

[m12n] final decision on oak-blob-plugins

hi as mentioned in the original summary we still need to make a final decision wrt oak-blob-plugins. in the initial poc we refactored (almost) everything from the o.a.j.oak.plugins.blob package space to a separate new module (oak-blob-plugins) with the option to finally merge it with oak-blob.

Re: [m12n] Looking at Document NodeStore (was: [m12] Effort to Improve Modularisation of Oak)

and improvements don't add more obstacles. kind regards angela On 19/04/17 14:26, "Julian Reschke" <julian.resc...@gmx.de> wrote: >On 2017-04-19 14:09, Angela Schreiber wrote: >> hi oak-devs >> >> michael asked about m12n effort for document nodestore: &g

[m12n] Looking at Document NodeStore (was: [m12] Effort to Improve Modularisation of Oak)

hi oak-devs michael asked about m12n effort for document nodestore: On 12/04/17 13:56, "Michael Dürig" wrote: [...] > >Is there plans to move document/rdb stores to separate modules or is >this beyond the current scope? > [...] i had a quick look this morning and got the

Re: [m12n] A new home for ApproximateCounter, NodeUtil and TreeUtil?

see also OAK-6093 <https://issues.apache.org/jira/browse/OAK-6093> for the corresponding JIRA ticket to make sure we consider that as part of the modularisation epic kind regards angela On 18/04/17 08:21, "Angela Schreiber" <anch...@adobe.com> wrote: >Hi Robert >

Re: [m12n] A new home for ApproximateCounter, NodeUtil and TreeUtil?

>it close to indexing would not be the right thing. We probably need to >involve Thomas here to provide his perspective. > >But then, I think this (and as well as the considerations around >NodeUtil and TreeUtil) should be tackled separately. > >Michael > >On 18.04.17

Re: [m12] Effort to Improve Modularisation of Oak

l need additional fixes. Thanks and kind regards angela On 18/04/17 08:57, "Michael Dürig" <mdue...@apache.org> wrote: > > >On 13.04.17 15:52, Angela Schreiber wrote: >> {quote} >> I would suggest to go with a naming scheme that reflects how modules >> woul

Re: [m12] Effort to Improve Modularisation of Oak

Hi Michael Sure... what modules do you think should be renamed? You mentioned oak-commons-run... anything else? Kind regards Angela On 18/04/17 08:57, "Michael Dürig" <mdue...@apache.org> wrote: > > >On 13.04.17 15:52, Angela Schreiber wrote: >> {quote} >>

Re: [m12n] A new home for ApproximateCounter, NodeUtil and TreeUtil?

NgKD8Q%3D=0 > >Robert > >On Thu, 2017-04-06 at 14:49 +, Angela Schreiber wrote: >> Hi Robert >> >> plugins.tree would feel natural to me. >> regarding the export: not sure about that either... the plugins.tree >> has >> some unfortunate depe

Re: [m12] Effort to Improve Modularisation of Oak

'oak-core' and didn't really fit into 'oak-commons' from my point of >>view. >> After all I wanted to avoid converting 'oak-commons' into a second >> 'oak-core' :-). >> That module is the one with the least consistency IMO. But things may >> clarify if we move on... I

Re: [m12] Effort to Improve Modularisation of Oak

is >this beyond the current scope? I guess that would be a natural step as we move on... but during the last week we didn't look into this. Kind regards Angela PS: will attach simplified picture to OAK-6073 to illustrated the big picture. > >Michael > >On 12.04.17 11:21, An

[m12] Effort to Improve Modularisation of Oak

Hi As mentioned my Marcel this morning [0] we had some offline discussions related to the oak-blob-azure module and how we could independently release it. While we didn't see a satisfying solution for the 1.6 branch, we concluded that we should pick up the modularisation discussion for address

Re: Backport of OAK-4933 to 1.6

Hi Marcel Thanks for the summary. From my understanding the proposal additionally included the wish that we move forward with the modularisation and aims for independent releases for the oak-blob-azure module in trunk. See OAK-6069 [0] and subtask OAK-6073 [1] for the corresponding JIRA issue

Re: [m12n] A new home for ApproximateCounter, NodeUtil and TreeUtil?

Hi Robert plugins.tree would feel natural to me. regarding the export: not sure about that either... the plugins.tree has some unfortunate dependencies e.g. to oak.core. so probably more work ahead in that area. kind regards angela On 06/04/17 16:41, "Robert Munteanu"

Re: [m12n] remove oak-core dep in oak-blob-*

hi davide actually we don't have oak-base :-) the mail might be a bit out of context... we only have it in a poc. you may want to take a look at that initial draft https://github.com/mreutegg/jackrabbit-oak/tree/m12n but please note that it is still heavily under construction... basically we

[m12n] OakInitializer located in org.apache.jackrabbit.oak.spi.lifecycle

Hi To me it looks odd that the OakInitializer utility is located in org.apache.jackrabbit.oak.spi.lifecycle. It is only used the by the Oak utility and by some test setups. Any objection against moving it to org.apache.jackrabbit.oak to reside along with the Oak utility? Kind regards Angela

[m12n] Location of ClusterRepositoryInfo in o.a.j.oak.plugins.identifier package

Hi While working on an initial PoC to modularise the Oak code base, I noticed the utility class ClusterRepositoryInfo. This class (only containing a single static method) is only used by NodeStore implementations and only depends on low level interfaces/classes. Consequently, I have the

Re: the broken JCR locking

wrote: >> hi Angela, >> >> On Wed, Apr 5, 2017 at 3:18 PM, Angela Schreiber <anch...@adobe.com> >>wrote: >>> ...Does no reply mean that everyone agrees with the proposed steps? >>>:-)... >> >> I missed it but as an Oak user +1 to the below

Re: the broken JCR locking

Hi Does no reply mean that everyone agrees with the proposed steps? :-) Kind regards Angela On 22/03/17 10:35, "Angela Schreiber" <anch...@adobe.com> wrote: >Hi Oak-Devs > >I just had another discussion with a colleague of mine asking why JCR >locking is not

Re: What's the contract of QueryBuilder.impersonates(String name)?

hi and what do we gain with that? except for the fact that api consumers have to create an Principal instance from a name? not sure if that makes sense... i'd rather just clarify the API contract in the javadoc. angela On 04/04/17 14:32, "Davide Giannella" wrote: >On

Re: What's the contract of QueryBuilder.impersonates(String name)?

Hi I don't know how Michael intended it to work originally. Given the fact that the impersonation setup is established and evaluated using principals I would expect it to be a principal name, which in the default implementation just can be any string value. Kind regards Angela On 03/04/17

Re: svn commit: r1789487 - /jackrabbit/oak/trunk/oak-upgrade/src/test/java/org/apache/jackrabbit/oak/upgrade/cli/JdbcToSegmentTest.java

thanks michael... i was just about to write a mail wondering if i am the only one that has this test failing :-) On 30/03/17 12:02, "mdue...@apache.org" wrote: >Author: mduerig >Date: Thu Mar 30 10:02:42 2017 >New Revision: 1789487 > >URL:

Re: New JIRA component for observation

ues which is >harder with current set where "core" component has lots of different >types of issues clubbed together >Chetan Mehrotra > > >On Tue, Mar 28, 2017 at 12:32 PM, Angela Schreiber <anch...@adobe.com> >wrote: >> i agree with marcel. >>

Re: Backport of OAK-4933 to 1.6

i was about to write pretty much the same thing :-) regards angela On 28/03/17 09:09, "Michael Dürig" wrote: > >As this is a new feature I would be interested in the motivation for >having to backport this. Generally we should only backport fixes for >defects. > >As Marcel

Re: Documenting enhancements done in Oak 1.6

hi chetan On 24/03/17 07:11, "Chetan Mehrotra" <chetan.mehro...@gmail.com> wrote: >On Thu, Mar 23, 2017 at 10:19 PM, Angela Schreiber <anch...@adobe.com> >wrote: >> i have been working on should already >> be included in the documentation because i try to

Re: New JIRA component for observation

i agree with marcel. in general i would rather move forward with the modularisation and then adjust jira accordingly. kind regards angela On 27/03/17 09:26, "Marcel Reutegger" wrote: >Hi, > >I'm wondering if this is the best approach. Initially we used the JIRA >component

Re: modify aggregated privilege

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)

Re: Documenting enhancements done in Oak 1.6

that is already documented... angela On 23/03/17 15:40, "Angela Schreiber" <anch...@adobe.com> 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 >

Re: Documenting enhancements done in Oak 1.6

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"

Re: Discrepancy between addAccessControlEntry and clear on versioned node

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

Re: oak-benchmarks and oak-run

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

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

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

Re: Merge policy for the 1.6 branch

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

Re: Merge policy for the 1.6 branch

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

Re: Merge policy for the 1.6 branch

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.

Re: Merge policy for the 1.6 branch

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

Re: Merging OAK-5784 into 1.6.1

updated documentation with the 2 points mentioned below at revision 1785128. On 24/02/17 11:40, "Angela Schreiber" <anch...@adobe.com> wrote: >Hi Chetan > >Thanks a lot for your input! >In fact I looked at the PropertyStateValue implementation and spotted the &

Re: Merging OAK-5784 into 1.6.1

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" <chetan.mehro...@gmail.com> wrote: >On Fri, Feb 24, 2017 at 4:10 PM, Angela Schreiber &

Re: Merging OAK-5784 into 1.6.1

ld >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 &g

Merging OAK-5784 into 1.6.1

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

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

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

Merging OAK-5654 into 1.6.1

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: Review OAK-5623

regards angela On 14/02/17 15:27, "Angela Schreiber" <anch...@adobe.com> 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 > >

Re: Review OAK-5623

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" <anch...@adobe.com> wrote: >Hi > >I would appreciate if you

Re: oak-run, diet and new module

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

Re: OAK-5025

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

Re: Oak 1.5.15 release plan

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: >> H

Re: Oak 1.5.15 release plan

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

Link to Security Summit

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.

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

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

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

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

Re: How to get principals from a session?

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, >

Re: unregister custom privilege

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)

Re: Why is nt:resource referencable?

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

Re: Why is nt:resource referencable?

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

Re: Why is nt:resource referencable?

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,

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

;chetan.mehro...@gmail.com> wrote: >Thanks for the feedback. Opened OAK-4567 to track the change > > >On Mon, Jul 18, 2016 at 12:14 PM, Angela Schreiber <anch...@adobe.com> >wrote: >> Additionally or alternatively we could create a separate method (e.g. >> putOak

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

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

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.3

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

Re: [VOTE] Release Apache Jackrabbit Oak 1.5.3

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;

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

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 <anch...@adobe.com>: > >> uh... so

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

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

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

gt;> (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 >Ia

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

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.

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

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" <chetan.mehro...@gmail.com> wrote: >Hi Angela, > >On Tue, May 10, 2016 at 9:49 PM, Angela Schreiber &

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

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

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

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

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

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

Re: Ability to Extend the SecurityProvideImpl Gone

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

<    1   2   3   4   5   6   >