[jira] [Resolved] (OAK-2948) Expose DefaultSyncHandler
[
https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved OAK-2948.
---
Resolution: Fixed
Fix Version/s: 1.3.0
I did some refactoring and moved the SyncContext to a new package:
{{org.apache.jackrabbit.oak.spi.security.authentication.external.basic.DefaultSyncContext}}
let me know if you want the sync context to be broken up more.
fixed in r1685189.
> Expose DefaultSyncHandler
> -
>
> Key: OAK-2948
> URL: https://issues.apache.org/jira/browse/OAK-2948
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Konrad Windszus
> Fix For: 1.3.0
>
>
> We do have the use case of extending the user sync. Unfortunately
> {{DefaultSyncHandler}} is not exposed, so if you want to change one single
> aspect of the user synchronisation you have to copy over the code from the
> {{DefaultSyncHandler}}. Would it be possible to make that class part of the
> exposed classes, so that deriving your own class from that DefaultSyncHandler
> is possible?
> Very often company LDAPs are not very standardized. In our case we face an
> issue, that the membership is being listed in a user attribute, rather than
> in a group attribute.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2945) Sampling rate feature CompactionGainEstimate is not efficient
[ https://issues.apache.org/jira/browse/OAK-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14584047#comment-14584047 ] Michael Marth commented on OAK-2945: [~mduerig], is there a reason why this is not resolved for 1.2.x branch or just a mistake? > Sampling rate feature CompactionGainEstimate is not efficient > - > > Key: OAK-2945 > URL: https://issues.apache.org/jira/browse/OAK-2945 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: compaction, gc > Fix For: 1.3.0, 1.0.15 > > > The sampling rate feature introduced with OAK-2595 is not efficient. It only > prevents uuids from being stored in the bloom filter while the visited set is > not affected and thus keeps growing. > I will remove the feature again for now. We should look for a better solution > once this becomes a problem. Will follow up on OAK-2939 re. this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2944) Support merge iterator for union order by queries
[ https://issues.apache.org/jira/browse/OAK-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Marth updated OAK-2944: --- Labels: perfomance (was: ) > Support merge iterator for union order by queries > - > > Key: OAK-2944 > URL: https://issues.apache.org/jira/browse/OAK-2944 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: query >Reporter: Amit Jain >Assignee: Amit Jain > Labels: perfomance > Fix For: 1.3.1 > > Attachments: OAK-2618.patch > > > Currently, any order by union queries (including optimized OR XPATH) scan a > much larger set when returning the results even when the individual queries > are sorted by the index itself. > We should have a merge iterator which would scan a much smaller set as the > individual queries would be sorted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2942) IllegalStateException thrown in Segment.pos()
[
https://issues.apache.org/jira/browse/OAK-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Marth updated OAK-2942:
---
Labels: resilience (was: )
> IllegalStateException thrown in Segment.pos()
> -
>
> Key: OAK-2942
> URL: https://issues.apache.org/jira/browse/OAK-2942
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Affects Versions: 1.2.2
>Reporter: Francesco Mari
> Labels: resilience
> Fix For: 1.3.3
>
> Attachments: ObservationBusyTest.java
>
>
> When I tried to put Oak under stress to reproduce OAK-2731, I experienced an
> {{IllegalStateException}} thrown by {{Segment.pos()}}. The full stack trace
> is the following:
> {noformat}
> java.lang.IllegalStateException
> at com.google.common.base.Preconditions.checkState(Preconditions.java:134)
> at org.apache.jackrabbit.oak.plugins.segment.Segment.pos(Segment.java:194)
> at
> org.apache.jackrabbit.oak.plugins.segment.Segment.readRecordId(Segment.java:337)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.getTemplateId(SegmentNodeState.java:70)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.getTemplate(SegmentNodeState.java:79)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:447)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStore$Commit.prepare(SegmentNodeStore.java:446)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStore$Commit.optimisticMerge(SegmentNodeStore.java:471)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStore$Commit.execute(SegmentNodeStore.java:527)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStore.merge(SegmentNodeStore.java:205)
> at org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:247)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.commit(SessionDelegate.java:341)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:487)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:424)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:268)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:421)
> at
> org.apache.jackrabbit.oak.jcr.observation.ObservationBusyTest$1.run(ObservationBusyTest.java:145)
> ... 6 more
> {noformat}
> In addition, the TarMK flushing thread throws an {{OutOfMemoryError}}:
> {noformat}
> Exception in thread "TarMK flush thread
> [/var/folders/zw/qns3kln16ld99frxtp263c8cgn/T/junit2925373080495354479],
> active since Mon Jun 01 18:48:19 CEST 2015, previous max duration 302ms"
> java.lang.OutOfMemoryError: Java heap space
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.createNewBuffer(SegmentWriter.java:91)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentWriter.flush(SegmentWriter.java:240)
> at
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore.flush(FileStore.java:596)
> at
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore$1.run(FileStore.java:411)
> at java.lang.Thread.run(Thread.java:695)
> at
> org.apache.jackrabbit.oak.plugins.segment.file.BackgroundThread.run(BackgroundThread.java:70)
> {noformat}
> The attached test case {{ObservationBusyTest.java}} allows me to reproduce
> consistently the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-1871) Support multi-column property indexes
[
https://issues.apache.org/jira/browse/OAK-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14584015#comment-14584015
]
Michael Marth commented on OAK-1871:
[~tmueller], I think this could be closed. We can always re-open if needed.
WDYT?
> Support multi-column property indexes
> -
>
> Key: OAK-1871
> URL: https://issues.apache.org/jira/browse/OAK-1871
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 1.4
>
>
> Currently, all property indexes are single-column. To speed up some use
> cases, the property index should support multiple columns. Example use case:
> Property "size" with low cardinality (low number of distinct values, for
> example "S", "M", "L", "XL"). Property "color" with low number of cardinality
> ("white", "black", "red",...). The query condition is "where size = 'L' and
> color = 'white'". The number of matching nodes is small.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-1871) Support multi-column property indexes
[
https://issues.apache.org/jira/browse/OAK-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Marth updated OAK-1871:
---
Issue Type: Improvement (was: Bug)
> Support multi-column property indexes
> -
>
> Key: OAK-1871
> URL: https://issues.apache.org/jira/browse/OAK-1871
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 1.4
>
>
> Currently, all property indexes are single-column. To speed up some use
> cases, the property index should support multiple columns. Example use case:
> Property "size" with low cardinality (low number of distinct values, for
> example "S", "M", "L", "XL"). Property "color" with low number of cardinality
> ("white", "black", "red",...). The query condition is "where size = 'L' and
> color = 'white'". The number of matching nodes is small.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2931) RDBDocumentStore: mitigate effects of large query result sets
[ https://issues.apache.org/jira/browse/OAK-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Marth updated OAK-2931: --- Labels: resilience (was: ) > RDBDocumentStore: mitigate effects of large query result sets > - > > Key: OAK-2931 > URL: https://issues.apache.org/jira/browse/OAK-2931 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: rdbmk >Affects Versions: 1.2.2, 1.0.14, 1.3 >Reporter: Julian Reschke >Assignee: Julian Reschke > Labels: resilience > Fix For: 1.3.0, 1.2.3, 1.0.15 > > > With the DocumentStore query API, large result sets can happen; and these are > returned as List, potentially causing large amounts of memory to be > allocated. > In the current implementation, the result list is generated based on a list > of internal row presentations (RDBRow). These are currently freed when the > method finishes. They should be freed as early as possible. > Furthermore, when the result set gets big, RDBDocumentStore should llog an > error containing the call chain, so that the component doing the excessive > query can be identified (it should use paging instead). > (For completeness: we could also change the code to lazily populate the list; > but that would be a bigger change) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2844) Introducing a simple document-based discovery-light service (to circumvent documentMk's eventual consistency delays)
[
https://issues.apache.org/jira/browse/OAK-2844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Marth updated OAK-2844:
---
Labels: resilience (was: )
> Introducing a simple document-based discovery-light service (to circumvent
> documentMk's eventual consistency delays)
>
>
> Key: OAK-2844
> URL: https://issues.apache.org/jira/browse/OAK-2844
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mongomk
>Reporter: Stefan Egli
> Labels: resilience
> Fix For: 1.4
>
> Attachments: InstanceStateChangeListener.java, OAK-2844.WIP-02.patch,
> OAK-2844.patch
>
>
> When running discovery.impl on a mongoMk-backed jcr repository, there are
> risks of hitting problems such as described in "SLING-3432
> pseudo-network-partitioning": this happens when a jcr-level heartbeat does
> not reach peers within the configured heartbeat timeout - it then treats that
> affected instance as dead, removes it from the topology, and continues with
> the remainings, potentially electing a new leader, running the risk of
> duplicate leaders. This happens when delays in mongoMk grow larger than the
> (configured) heartbeat timeout. These problems ultimately are due to the
> 'eventual consistency' nature of, not only mongoDB, but more so of mongoMk.
> The only alternative so far is to increase the heartbeat timeout to match the
> expected or measured delays that mongoMk can produce (under say given
> load/performance scenarios).
> Assuming that mongoMk will always carry a risk of certain delays and a
> maximum, reasonable (for discovery.impl timeout that is) maximum cannot be
> guaranteed, a better solution is to provide discovery with more 'real-time'
> like information and/or privileged access to mongoDb.
> Here's a summary of alternatives that have so far been floating around as a
> solution to circumvent eventual consistency:
> # expose existing (jmx) information about active 'clusterIds' - this has
> been proposed in SLING-4603. The pros: reuse of existing functionality. The
> cons: going via jmx, binding of exposed functionality as 'to be maintained
> API'
> # expose a plain mongo db/collection (via osgi injection) such that a higher
> (sling) level discovery could directly write heartbeats there. The pros:
> heartbeat latency would be minimal (assuming the collection is not sharded).
> The cons: exposes a mongo db/collection potentially also to anyone else, with
> the risk of opening up to unwanted possibilities
> # introduce a simple 'discovery-light' API to oak which solely provides
> information about which instances are active in a cluster. The implementation
> of this is not exposed. The pros: no need to expose a mongoDb/collection,
> allows any other jmx-functionality to remain unchanged. The cons: a new API
> that must be maintained
> This ticket is about the 3rd option, about a new mongo-based discovery-light
> service that is introduced to oak. The functionality in short:
> * it defines a 'local instance id' that is non-persisted, ie can change at
> each bundle activation.
> * it defines a 'view id' that uniquely identifies a particular incarnation
> of a 'cluster view/state' (which is: a list of active instance ids)
> * and it defines a list of active instance ids
> * the above attributes are passed to interested components via a listener
> that can be registered. that listener is called whenever the discovery-light
> notices the cluster view has changed.
> While the actual implementation could in fact be based on the existing
> {{getActiveClusterNodes()}} {{getClusterId()}} of the
> {{DocumentNodeStoreMBean}}, the suggestion is to not fiddle with that part,
> as that has dependencies to other logic. But instead, the suggestion is to
> create a dedicated, other, collection ('discovery') where heartbeats as well
> as the currentView are stored.
> Will attach a suggestion for an initial version of this for review.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2795) TarMK revision cleanup message too verbose.
[
https://issues.apache.org/jira/browse/OAK-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Marth updated OAK-2795:
---
Fix Version/s: 1.3.3
> TarMK revision cleanup message too verbose.
> ---
>
> Key: OAK-2795
> URL: https://issues.apache.org/jira/browse/OAK-2795
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Reporter: Zygmunt Wiercioch
>Priority: Minor
> Fix For: 1.3.3
>
>
> The segment GC message can be thousands of lines long on a system which
> experienced a lot of activity. For example, in my test, I had:
> {noformat}
> org.apache.jackrabbit.oak.plugins.segment.file.TarReader-GC Cleaned segments
> from data8a.tar:
> 4b6882e7-babe-4854-a966-c3a630c338c6, 506a2eb3-92a6-4b83-a320-5cc5ac304302,
> f179e4b1-acec-4a5d-a686-bf5e97828563, 8c6b3a4d-c327-4701-affb-fcd055c4aa67,
> {noformat}
> followed by approximately 40,000 more lines.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2795) TarMK revision cleanup message too verbose.
[
https://issues.apache.org/jira/browse/OAK-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Marth updated OAK-2795:
---
Priority: Minor (was: Major)
> TarMK revision cleanup message too verbose.
> ---
>
> Key: OAK-2795
> URL: https://issues.apache.org/jira/browse/OAK-2795
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Reporter: Zygmunt Wiercioch
>Priority: Minor
>
> The segment GC message can be thousands of lines long on a system which
> experienced a lot of activity. For example, in my test, I had:
> {noformat}
> org.apache.jackrabbit.oak.plugins.segment.file.TarReader-GC Cleaned segments
> from data8a.tar:
> 4b6882e7-babe-4854-a966-c3a630c338c6, 506a2eb3-92a6-4b83-a320-5cc5ac304302,
> f179e4b1-acec-4a5d-a686-bf5e97828563, 8c6b3a4d-c327-4701-affb-fcd055c4aa67,
> {noformat}
> followed by approximately 40,000 more lines.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583943#comment-14583943
]
Alexander Klimetschek commented on OAK-2981:
What JCR logging? I did not find any in Oak.
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Alexander Klimetschek
>Assignee: angela
>Priority: Minor
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2874) [ldap] enable listUsers to work for more than 1000 external users
[ https://issues.apache.org/jira/browse/OAK-2874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583911#comment-14583911 ] Tobias Bocanegra commented on OAK-2874: --- we it be enough to fix the LDAP provider to properly fetch more if the initial search result is capped? > [ldap] enable listUsers to work for more than 1000 external users > - > > Key: OAK-2874 > URL: https://issues.apache.org/jira/browse/OAK-2874 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Affects Versions: 1.2.1 >Reporter: Nicolas Peltier > > LDAP servers are usually limited to return 1000 search results. Currently > LdapIdentityProvider.listUsers() doesn't take care of that limitation and > prevent the client user to retrieve more.(cc [~tripod]) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-2874) [ldap] enable listUsers to work for more than 1000 external users
[ https://issues.apache.org/jira/browse/OAK-2874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583911#comment-14583911 ] Tobias Bocanegra edited comment on OAK-2874 at 6/12/15 7:06 PM: would it be enough to fix the LDAP provider to properly fetch more if the initial search result is capped? was (Author: tripod): we it be enough to fix the LDAP provider to properly fetch more if the initial search result is capped? > [ldap] enable listUsers to work for more than 1000 external users > - > > Key: OAK-2874 > URL: https://issues.apache.org/jira/browse/OAK-2874 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Affects Versions: 1.2.1 >Reporter: Nicolas Peltier > > LDAP servers are usually limited to return 1000 search results. Currently > LdapIdentityProvider.listUsers() doesn't take care of that limitation and > prevent the client user to retrieve more.(cc [~tripod]) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583877#comment-14583877
]
Tobias Bocanegra commented on OAK-2981:
---
but you can also turn on JCR logging...and you will be surprised even more :-)
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Alexander Klimetschek
>Assignee: angela
>Priority: Minor
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583873#comment-14583873
]
Alexander Klimetschek commented on OAK-2981:
No, I don't understand what's happening in reality, unless I actually SEE it.
Because there is always code from many people and different modules involved
that "you" don't have control of.
Especially when you want people to design minimal access permissions for their
application (and not just broad read on everything), it is vital to see what
happens. Otherwise it's pure blind flight or theoretical.
Also, for performace reasons it's good to see what is maybe unnecessarily
accessed without any developer actively knowing. When I turned this logging on
for our application, I was very surprised about quite a few things!
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Alexander Klimetschek
>Assignee: angela
>Priority: Minor
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583817#comment-14583817
]
angela edited comment on OAK-2981 at 6/12/15 6:15 PM:
--
well... i fail to see the benefit of this kind of logging. for development you
don't need it because you hopefully understand what you are doing and don't
need a log-trace in order to properly setup your permissions (trial and error
approach is the kind of thing i wouldn't want a developer to do in the security
area). and for debugging an application which has troubles this kind of
super-verbose log out put is not going to help in any way. what you need for
the latter is a tool that allows you shows the effective permissions on one
hand the the effective access control setup on the other hand; both for
individual principals and an (arbitrary) set of principals.
-1 for this approach which will not help you understand why you have a given
result. the fact that have it can be seen with regular log files already.
was (Author: anchela):
well... i fail to see the benefit of this kind of logging. for development you
don't need it because you hopefully understand what you are doing and don't
need a log-trace in order to properly setup your permissions (trial and error
approach is the kind of thing i wouldn't want a developer to do in the security
area). and for debugging an application which has troubles this kind of
super-verbose log out put is not going to help in any way. what you need for
the latter is a tool that allows you shows the effective permissions on one
hand the the effective access control setup on the other hand; both for
individual principals and an (arbitrary) set of principals.
-1 for this approach.
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Alexander Klimetschek
>Assignee: angela
>Priority: Minor
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583817#comment-14583817
]
angela edited comment on OAK-2981 at 6/12/15 6:14 PM:
--
well... i fail to see the benefit of this kind of logging. for development you
don't need it because you hopefully understand what you are doing and don't
need a log-trace in order to properly setup your permissions (trial and error
approach is the kind of thing i wouldn't want a developer to do in the security
area). and for debugging an application which has troubles this kind of
super-verbose log out put is not going to help in any way. what you need for
the latter is a tool that allows you shows the effective permissions on one
hand the the effective access control setup on the other hand; both for
individual principals and an (arbitrary) set of principals.
-1 for this approach.
was (Author: anchela):
well... i fail to see the benefit of this kind of logging. for development you
don't need it because you hopefully understand what you are doing and don't
need a log-trace in order to properly setup your permissions (trial and error
approach is the kind of thing i wouldn't want a developer to do in the security
area). and for debugging an application which has troubles this kind of
super-verbose log out put is not going to help in any way. what you need for
the latter is a tool that allows you should the effective permissions on one
hand the the effective permission setup on the other hand; both for individual
principals and an arbitrary set of principals.
-1 for this approach.
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Alexander Klimetschek
>Assignee: angela
>Priority: Minor
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583817#comment-14583817
]
angela commented on OAK-2981:
-
well... i fail to see the benefit of this kind of logging. for development you
don't need it because you hopefully understand what you are doing and don't
need a log-trace in order to properly setup your permissions (trial and error
approach is the kind of thing i wouldn't want a developer to do in the security
area). and for debugging an application which has troubles this kind of
super-verbose log out put is not going to help in any way. what you need for
the latter is a tool that allows you should the effective permissions on one
hand the the effective permission setup on the other hand; both for individual
principals and an arbitrary set of principals.
-1 for this approach.
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Alexander Klimetschek
>Assignee: angela
>Priority: Minor
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2984) Set blobs collection on separate database
[ https://issues.apache.org/jira/browse/OAK-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583748#comment-14583748 ] Norberto Leite commented on OAK-2984: - Hi [~243826], I would expect, perhaps just a marginal small test/environment, but some improvement on large dataset. Having separate disk should magnify does results although significant improvement would only be detected on saturated IO bound disks. I'll take the action of review the test case and rerunning on a large dataset. I'll let you know about it. N. > Set blobs collection on separate database > - > > Key: OAK-2984 > URL: https://issues.apache.org/jira/browse/OAK-2984 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Norberto Leite > Labels: performance > > MongoDB allows the creation of several different database namespaces to allow > concept separation, between different applications and separate workloads to > perform conceptual and physical isolation. > It also allows different databases to be set on [different mount points | > http://docs.mongodb.org/manual/reference/configuration-options/#storage.directoryPerDB] > which for this particular workload (nodes vs blobs) would be greatly > appreciated. Having different physical disks would be to avoid IO contention > provoked by demanding large blob operations upload operations on disk level. > The implementation details would be as simple has defining an option that > would require a *blobs database name* > N. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583723#comment-14583723
]
Alexander Klimetschek commented on OAK-2981:
Sure, this is only for development and debugging, never for production. It also
creates a LOT of messages (1+ MB per typical page view, depending on the app),
so you can only use it with controlled traffic anyway.
It has a special category and uses TRACE, so not likely at all to be
accidentally enabled.
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Alexander Klimetschek
>Assignee: angela
>Priority: Minor
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2984) Set blobs collection on separate database
[ https://issues.apache.org/jira/browse/OAK-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583624#comment-14583624 ] Chetan Mehrotra commented on OAK-2984: -- [~nleite] Would this also provide better concurrent write throughput. So far my understanding was that Mongo 2.6.x had a db level locking and having collection in separate database would help. However test done as part of OAK-1153 did not show much difference. May be testcase were implemented incorrectly. So wanted to confirm if there are other benefit apart from different mount point? > Set blobs collection on separate database > - > > Key: OAK-2984 > URL: https://issues.apache.org/jira/browse/OAK-2984 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Norberto Leite > Labels: performance > > MongoDB allows the creation of several different database namespaces to allow > concept separation, between different applications and separate workloads to > perform conceptual and physical isolation. > It also allows different databases to be set on [different mount points | > http://docs.mongodb.org/manual/reference/configuration-options/#storage.directoryPerDB] > which for this particular workload (nodes vs blobs) would be greatly > appreciated. Having different physical disks would be to avoid IO contention > provoked by demanding large blob operations upload operations on disk level. > The implementation details would be as simple has defining an option that > would require a *blobs database name* > N. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-2984) Set blobs collection on separate database
Norberto Leite created OAK-2984: --- Summary: Set blobs collection on separate database Key: OAK-2984 URL: https://issues.apache.org/jira/browse/OAK-2984 Project: Jackrabbit Oak Issue Type: Improvement Components: mongomk Reporter: Norberto Leite MongoDB allows the creation of several different database namespaces to allow concept separation, between different applications and separate workloads to perform conceptual and physical isolation. It also allows different databases to be set on [different mount points | http://docs.mongodb.org/manual/reference/configuration-options/#storage.directoryPerDB] which for this particular workload (nodes vs blobs) would be greatly appreciated. Having different physical disks would be to avoid IO contention provoked by demanding large blob operations upload operations on disk level. The implementation details would be as simple has defining an option that would require a *blobs database name* N. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583563#comment-14583563
]
Tobias Bocanegra commented on OAK-2981:
---
but it is tremendous helpful when debugging an application. similar to the JCR
log, that logs ALL JCR calls. If we could make this available to be used when
required during profiling, that would really help.
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Alexander Klimetschek
>Assignee: angela
>Priority: Minor
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2961) Async index fails with OakState0001: Unresolved conflicts in /:async
[
https://issues.apache.org/jira/browse/OAK-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583526#comment-14583526
]
Chetan Mehrotra commented on OAK-2961:
--
Looks like the issue is in AsyncIndexUpdate around what is considered as
concurrent update. The above test runs a 5 node cluster and creates and index
and triggers a reindex. It can happen and infact here does happen that on 2
cluster node AsyncIndex job is fired at same time and they both try to set the
lease which can result in conflict at DocumentStore layer (and hence not
detected by CommitHook). For e.g. in this test following logs is seen where it
can be seen that {{async-lease}} is different
{noformat}
19:09:26.346 DEBUG [oak-scheduled-executor-23] ConflictValidator.java:91 Commit
failed due to unresolved conflicts in /:async = {addExistingProperty =
{async-lease = {1434118165914,1434118164643}},changeChangedProperty =
{async-temp = {,}}}
org.apache.jackrabbit.oak.api.CommitFailedException: OakState0001: Unresolved
conflicts in /:async
at
org.apache.jackrabbit.oak.plugins.commit.ConflictValidator.failOnMergeConflict(ConflictValidator.java:84)
[classes/:na]
at
org.apache.jackrabbit.oak.plugins.commit.ConflictValidator.propertyAdded(ConflictValidator.java:54)
[classes/:na]
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.propertyAdded(EditorDiff.java:82)
[classes/:na]
at
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:378)
[classes/:na]
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
[classes/:na]
at
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:399)
[classes/:na]
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
[classes/:na]
at
org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
[classes/:na]
at
org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61)
[classes/:na]
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:543)
[classes/:na]
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:223)
[classes/:na]
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:171)
[classes/:na]
at
org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:158)
[classes/:na]
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1495)
[classes/:na]
at
org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.mergeWithConcurrencyCheck(AsyncIndexUpdate.java:467)
[classes/:na]
at
org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.access$400(AsyncIndexUpdate.java:76)
[classes/:na]
at
org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate$AsyncUpdateCallback.(AsyncIndexUpdate.java:201)
[classes/:na]
at
org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.updateIndex(AsyncIndexUpdate.java:371)
[classes/:na]
at
org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.run(AsyncIndexUpdate.java:320)
[classes/:na]
19:09:26.347 WARN [oak-scheduled-executor-23] AsyncIndexUpdate.java:342
[async] The index update failed
org.apache.jackrabbit.oak.api.CommitFailedException: OakState0001: Unresolved
conflicts in /:async
at
org.apache.jackrabbit.oak.plugins.commit.ConflictValidator.failOnMergeConflict(ConflictValidator.java:84)
~[classes/:na]
at
org.apache.jackrabbit.oak.plugins.commit.ConflictValidator.propertyAdded(ConflictValidator.java:54)
~[classes/:na]
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.propertyAdded(EditorDiff.java:82)
~[classes/:na]
at
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:378)
~[classes/:na]
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148)
~[classes/:na]
at
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:399)
~[classes/:na]
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
~[classes/:na]
at
org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
~[classes/:na]
at
org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61)
~[classes/:na]
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:543)
~[classes/:na]
at
org.apache.jackrabbit.oak.plugins.document.Document
[jira] [Resolved] (OAK-2979) JournalTest.cleanupTest reliably fails on Windows
[
https://issues.apache.org/jira/browse/OAK-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke resolved OAK-2979.
-
Resolution: Fixed
see r1685075
> JournalTest.cleanupTest reliably fails on Windows
> -
>
> Key: OAK-2979
> URL: https://issues.apache.org/jira/browse/OAK-2979
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Attachments: OAK-2979.patch
>
>
> {noformat}
> cleanupTest(org.apache.jackrabbit.oak.plugins.document.JournalTest) Time
> elapsed: 0.12 sec <<< FAILURE!
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at
> org.apache.jackrabbit.oak.plugins.document.JournalTest.cleanupTest(JournalTest.java:199)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-2979) JournalTest.cleanupTest reliably fails on Windows
[
https://issues.apache.org/jira/browse/OAK-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke reassigned OAK-2979:
---
Assignee: Julian Reschke (was: Stefan Egli)
> JournalTest.cleanupTest reliably fails on Windows
> -
>
> Key: OAK-2979
> URL: https://issues.apache.org/jira/browse/OAK-2979
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Attachments: OAK-2979.patch
>
>
> {noformat}
> cleanupTest(org.apache.jackrabbit.oak.plugins.document.JournalTest) Time
> elapsed: 0.12 sec <<< FAILURE!
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at
> org.apache.jackrabbit.oak.plugins.document.JournalTest.cleanupTest(JournalTest.java:199)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583321#comment-14583321
]
angela commented on OAK-2981:
-
what i forget to mention above: we _deliberately_ don't expose any information
where and who has which permissions. this is not a leftover or dirty hack but a
conscious decision not to expose permission information associated with path
and principals neither in the log file nor in the exception(s). from a security
point of view this is a no-go.
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Alexander Klimetschek
>Assignee: angela
>Priority: Minor
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-2983) Permissions lack WRITE
angela created OAK-2983: --- Summary: Permissions lack WRITE Key: OAK-2983 URL: https://issues.apache.org/jira/browse/OAK-2983 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: angela Assignee: angela while oak itself never checks for the composite 'WRITE' permission it makes sense to add the aggregation to the constants (as we already have for REMOVE). thanks [~pfa...@adobe.com] for spotting this and the suggestion! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2979) JournalTest.cleanupTest reliably fails on Windows
[
https://issues.apache.org/jira/browse/OAK-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583232#comment-14583232
]
Stefan Egli commented on OAK-2979:
--
[~reschke], yes please, thx!
> JournalTest.cleanupTest reliably fails on Windows
> -
>
> Key: OAK-2979
> URL: https://issues.apache.org/jira/browse/OAK-2979
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Julian Reschke
>Assignee: Stefan Egli
> Attachments: OAK-2979.patch
>
>
> {noformat}
> cleanupTest(org.apache.jackrabbit.oak.plugins.document.JournalTest) Time
> elapsed: 0.12 sec <<< FAILURE!
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at
> org.apache.jackrabbit.oak.plugins.document.JournalTest.cleanupTest(JournalTest.java:199)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583226#comment-14583226
]
angela edited comment on OAK-2981 at 6/12/15 10:37 AM:
---
while i agree on the use case of displaying both the effective access control
content and the effective permissions for a given (set of) principal(s) the
implementation is not sensible at all as it logs upon permission evaluation.
so, a) the subject doesn't match the effective code and b) mixes access control
management and permission evaluation and c) it doesn't log access control at
all... not really demonstrating an understanding of the concepts and design i
have to say... ;-)
i would rather go for tool that displays the effective permissions than a
logger that pollutes the log-file during each and every single access. that is
not going to help anybody.
was (Author: anchela):
while i agree on the use case the implementation is not sensible at all as it
logs upon permission evaluation.
so, the subject doesn't match the effective code and mixes access control
management and permission evaluation... not really demonstrating an
understanding of the concepts and design i have to say... ;-)
i would rather go for tool that displays the effective permissions than a
logger that pollutes the log-file during each and every single access. that is
not going to help anybody.
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Alexander Klimetschek
>Assignee: angela
>Priority: Minor
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583226#comment-14583226
]
angela edited comment on OAK-2981 at 6/12/15 10:35 AM:
---
while i agree on the use case the implementation is not sensible at all as it
logs upon permission evaluation.
so, the subject doesn't match the effective code and mixes access control
management and permission evaluation... not really demonstrating an
understanding of the concepts and design i have to say... ;-)
i would rather go for tool that displays the effective permissions than a
logger that pollutes the log-file during each and every single access. that is
not going to help anybody.
was (Author: anchela):
while i agree on the use case the implementation is not sensible at all as it
logs upon permission evaluation.
so, the subject doesn't match the effective code and mixes access control
management and permission evaluation.
i would rather go for tool that displays the effective permissions than a
logger that pollutes the log-file during each and every single access. that is
not going to help anybody.
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Alexander Klimetschek
>Assignee: angela
>Priority: Minor
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-2981:
Component/s: (was: security)
core
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
>Reporter: Alexander Klimetschek
>Assignee: angela
>Priority: Minor
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583226#comment-14583226
]
angela commented on OAK-2981:
-
while i agree on the use case the implementation is not sensible at all as it
logs upon permission evaluation.
so, the subject doesn't match the effective code and mixes access control
management and permission evaluation.
i would rather go for tool that displays the effective permissions than a
logger that pollutes the log-file during each and every single access. that is
not going to help anybody.
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: security
>Reporter: Alexander Klimetschek
>Assignee: angela
>Priority: Minor
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-2981:
Priority: Minor (was: Major)
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: security
>Reporter: Alexander Klimetschek
>Assignee: angela
>Priority: Minor
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela reassigned OAK-2981:
---
Assignee: angela
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: security
>Reporter: Alexander Klimetschek
>Assignee: angela
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-2982) BasicDocumentStoreTest: separate actual unit tests from performance tests
Julian Reschke created OAK-2982: --- Summary: BasicDocumentStoreTest: separate actual unit tests from performance tests Key: OAK-2982 URL: https://issues.apache.org/jira/browse/OAK-2982 Project: Jackrabbit Oak Issue Type: Sub-task Components: rdbmk Affects Versions: 1.2.2, 1.0.15, 1.3 Reporter: Julian Reschke Fix For: 1.3.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2979) JournalTest.cleanupTest reliably fails on Windows
[
https://issues.apache.org/jira/browse/OAK-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-2979:
Assignee: Stefan Egli (was: Julian Reschke)
> JournalTest.cleanupTest reliably fails on Windows
> -
>
> Key: OAK-2979
> URL: https://issues.apache.org/jira/browse/OAK-2979
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Julian Reschke
>Assignee: Stefan Egli
> Attachments: OAK-2979.patch
>
>
> {noformat}
> cleanupTest(org.apache.jackrabbit.oak.plugins.document.JournalTest) Time
> elapsed: 0.12 sec <<< FAILURE!
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at
> org.apache.jackrabbit.oak.plugins.document.JournalTest.cleanupTest(JournalTest.java:199)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2979) JournalTest.cleanupTest reliably fails on Windows
[
https://issues.apache.org/jira/browse/OAK-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583174#comment-14583174
]
Julian Reschke commented on OAK-2979:
-
Yes, that seems to help. Should I commit the change?
> JournalTest.cleanupTest reliably fails on Windows
> -
>
> Key: OAK-2979
> URL: https://issues.apache.org/jira/browse/OAK-2979
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Attachments: OAK-2979.patch
>
>
> {noformat}
> cleanupTest(org.apache.jackrabbit.oak.plugins.document.JournalTest) Time
> elapsed: 0.12 sec <<< FAILURE!
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at
> org.apache.jackrabbit.oak.plugins.document.JournalTest.cleanupTest(JournalTest.java:199)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-2979) JournalTest.cleanupTest reliably fails on Windows
[
https://issues.apache.org/jira/browse/OAK-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke reassigned OAK-2979:
---
Assignee: Julian Reschke
> JournalTest.cleanupTest reliably fails on Windows
> -
>
> Key: OAK-2979
> URL: https://issues.apache.org/jira/browse/OAK-2979
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Attachments: OAK-2979.patch
>
>
> {noformat}
> cleanupTest(org.apache.jackrabbit.oak.plugins.document.JournalTest) Time
> elapsed: 0.12 sec <<< FAILURE!
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at
> org.apache.jackrabbit.oak.plugins.document.JournalTest.cleanupTest(JournalTest.java:199)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583104#comment-14583104
]
Chetan Mehrotra commented on OAK-2981:
--
+1 looks pretty useful. Along with [Sling
Tracer|http://sling.apache.org/documentation/bundles/log-tracers.html] this
would enable a user to precisely see whats happening for given request.
Looking at patch you can avoid those joining logic with [Guava
Joiner|https://code.google.com/p/guava-libraries/wiki/StringsExplained#Joiner]
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: security
>Reporter: Alexander Klimetschek
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2981) Access control logging
[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583099#comment-14583099
]
Bertrand Delacretaz commented on OAK-2981:
--
Looks useful to me.
If the log4j APIs used are recent enough it might be good to add an slf4j
Marker in the logAccess(...) method, to help focus on those messages when
needed. Something like
{code}
private final static Marker AC_MARKER =
MarkerFactory.getMarker("Oak.AccessControl");
...
private void logAccess(String path, AccessResult isGranted, String...
permissions) {
log.trace(
AC_MARKER,
"[{}] {} {} [{}]",
user,
...
{code}
> Access control logging
> --
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: security
>Reporter: Alexander Klimetschek
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [aklim...@adobe.com] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2707) Performance: Consider cache for SessionImpl#getNamespacePrefixes
[ https://issues.apache.org/jira/browse/OAK-2707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Richard updated OAK-2707: -- Attachment: OAK-2707.patch [~anchela], in Sling the namespaces are read when you read the first property of a resource which contains a colon. Thanks to some other changes, we could reduce the overhead already to around 5% of the rendering time, but it would be great if we could remove it entirely. I have attached a patch with a namespace cache. Can you please review it? It still contains a few todos with things I wasn't sure about. > Performance: Consider cache for SessionImpl#getNamespacePrefixes > > > Key: OAK-2707 > URL: https://issues.apache.org/jira/browse/OAK-2707 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Affects Versions: 1.1.7 >Reporter: Joel Richard >Priority: Critical > Labels: performance > Fix For: 1.3.1 > > Attachments: OAK-2707.patch, Screen Shot 2015-03-30 at 08.38.58.png > > > Sesison#getNamespacePrefixes is heavily used in Sling (see > org.apache.sling.jcr.resource.JcrPropertyMap#escapeKeyName) and can easily be > called 5000-8000 times per page load. > Therefore, it adds 10-15% page rendering overhead for Sling-based websites > (see attachment). Would it be possible to add either a global cache or at > least a session cache for this method? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
