[jira] [Closed] (OAK-8198) Build Jackrabbit Oak #2066 failed

[Marcel Reutegger (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-8198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Reutegger closed OAK-8198.
-

> Build Jackrabbit Oak #2066 failed
> -
>
> Key: OAK-8198
> URL: https://issues.apache.org/jira/browse/OAK-8198
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #2066 has failed.
> First failed run: [Jackrabbit Oak 
> #2066|https://builds.apache.org/job/Jackrabbit%20Oak/2066/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/2066/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (OAK-8198) Build Jackrabbit Oak #2066 failed

[Marcel Reutegger (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-8198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Reutegger resolved OAK-8198.
---
Resolution: Duplicate

> Build Jackrabbit Oak #2066 failed
> -
>
> Key: OAK-8198
> URL: https://issues.apache.org/jira/browse/OAK-8198
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #2066 has failed.
> First failed run: [Jackrabbit Oak 
> #2066|https://builds.apache.org/job/Jackrabbit%20Oak/2066/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/2066/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-8186) Create API in OAK for file access to binaries in the repository.

[JIRA]

[ 
https://issues.apache.org/jira/browse/OAK-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812175#comment-16812175
 ] 

Michael Dürig commented on OAK-8186:


Thanks for these clarifications [~mattvryan]. I agree with you that at this 
point it is not clear why we should implement this into Oak. IMO this only 
leads to a tighter coupling whereas implementing a set of utilities for 
streaming a {{Binary}} into a temp file would be more versatile.

> Create API in OAK for file access to binaries in the repository.
> 
>
> Key: OAK-8186
> URL: https://issues.apache.org/jira/browse/OAK-8186
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>Reporter: Henry Saginor
>Priority: Major
> Attachments: OAK File Access.jpg
>
>
> To get file access applications normally write binaries to temp files. It 
> would be nice if an API existed to get file access directly from OAK. This 
> might also meet some use cases documented at 
> [https://wiki.apache.org/jackrabbit/JCR%20Binary%20Usecase]
> Suggested API and implementation can be found here [1]. Also, see attached 
> diagram [2].
> I can create a patch if I can get some feedback. Note that suggested API 
> makes it explicit that a temp file is created. I am not sure if direct access 
> to files in datasore would be safe. But I am open to suggestions.
> [1]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/FileReferencable.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReference.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReferenceProvider.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/FileDSBlobTempFileReference.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/DataStoreBlobStore.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentBlob.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/value/jcr/BinaryImpl.java]
> [2]
> !OAK File Access.jpg!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-8201) RDBDocumentStore in ReadOnly mode should never modify persistence

[Julian Reschke (JIRA)]

Julian Reschke created OAK-8201:
---

 Summary: RDBDocumentStore in ReadOnly mode should never modify 
persistence
 Key: OAK-8201
 URL: https://issues.apache.org/jira/browse/OAK-8201
 Project: Jackrabbit Oak
  Issue Type: Technical task
  Components: rdbmk
Reporter: Julian Reschke
Assignee: Julian Reschke






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-8200) MongoDocumentStore in ReadOnly mode should never modify persistence

[Julian Reschke (JIRA)]

Julian Reschke created OAK-8200:
---

 Summary: MongoDocumentStore in ReadOnly mode should never modify 
persistence
 Key: OAK-8200
 URL: https://issues.apache.org/jira/browse/OAK-8200
 Project: Jackrabbit Oak
  Issue Type: Technical task
  Components: mongomk
Reporter: Julian Reschke






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (OAK-8200) MongoDocumentStore in ReadOnly mode should never modify persistence

[Marcel Reutegger (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-8200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Reutegger reassigned OAK-8200:
-

Assignee: Marcel Reutegger

> MongoDocumentStore in ReadOnly mode should never modify persistence
> ---
>
> Key: OAK-8200
> URL: https://issues.apache.org/jira/browse/OAK-8200
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: mongomk
>Reporter: Julian Reschke
>Assignee: Marcel Reutegger
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-8200) MongoDocumentStore in ReadOnly mode should never modify persistence

[Marcel Reutegger (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-8200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812395#comment-16812395
 ] 

Marcel Reutegger commented on OAK-8200:
---

The MongoDocumentStore now creates indexes only when not in read-only mode.

Done in trunk: http://svn.apache.org/r1857104

> MongoDocumentStore in ReadOnly mode should never modify persistence
> ---
>
> Key: OAK-8200
> URL: https://issues.apache.org/jira/browse/OAK-8200
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: mongomk
>Reporter: Julian Reschke
>Assignee: Marcel Reutegger
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (OAK-8200) MongoDocumentStore in ReadOnly mode should never modify persistence

[Marcel Reutegger (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-8200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Reutegger resolved OAK-8200.
---
   Resolution: Fixed
Fix Version/s: 1.12.0

> MongoDocumentStore in ReadOnly mode should never modify persistence
> ---
>
> Key: OAK-8200
> URL: https://issues.apache.org/jira/browse/OAK-8200
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: mongomk
>Reporter: Julian Reschke
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.12.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-8202) RemoteBlobProcessor should print a stack trace of the exceptions it swallows

[Francesco Mari (JIRA)]

Francesco Mari created OAK-8202:
---

 Summary: RemoteBlobProcessor should print a stack trace of the 
exceptions it swallows
 Key: OAK-8202
 URL: https://issues.apache.org/jira/browse/OAK-8202
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: segment-tar
Reporter: Francesco Mari
Assignee: Francesco Mari


In order to cope with the dryness of the {{BlobStore}} and {{DataStore}} API, 
{{RemoteBlobProcessor#shouldFetchBinary}} relies on exceptions to implement 
part of its logic. While this is a bad development practice, it was the only 
way to cope with in-memory binary IDs without spending excessive amounts of 
network and CPU. To Improve the transparency of the system, 
{{RemoteBlobProcessor}} should print a message at WARN level every time it 
swallows an exception.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812442#comment-16812442
 ] 

Julian Reschke commented on OAK-6880:
-

People affected by thus please compare your local copy of the solr-parent 5.5.5 
pom with 
.

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-8146) oak-run support for inspecting/modifying clusterNodeInfo

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812449#comment-16812449
 ] 

Julian Reschke commented on OAK-8146:
-

WIP: https://issues.apache.org/jira/secure/attachment/12965201/OAK-8146.diff

> oak-run support for inspecting/modifying clusterNodeInfo
> 
>
> Key: OAK-8146
> URL: https://issues.apache.org/jira/browse/OAK-8146
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: documentmk, run
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Attachments: OAK-8146.diff, OAK-8146.diff
>
>
> - readable dump of cluster node info entries
> - command to purge selected entries



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-8146) oak-run support for inspecting/modifying clusterNodeInfo

[Julian Reschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke updated OAK-8146:

Attachment: OAK-8146.diff

> oak-run support for inspecting/modifying clusterNodeInfo
> 
>
> Key: OAK-8146
> URL: https://issues.apache.org/jira/browse/OAK-8146
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: documentmk, run
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Attachments: OAK-8146.diff, OAK-8146.diff
>
>
> - readable dump of cluster node info entries
> - command to purge selected entries



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (OAK-8202) RemoteBlobProcessor should print a stack trace of the exceptions it swallows

[Francesco Mari (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Mari resolved OAK-8202.
-
   Resolution: Fixed
Fix Version/s: 1.10.3

Fixed at r1857109.

> RemoteBlobProcessor should print a stack trace of the exceptions it swallows
> 
>
> Key: OAK-8202
> URL: https://issues.apache.org/jira/browse/OAK-8202
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.10.3
>
>
> In order to cope with the dryness of the {{BlobStore}} and {{DataStore}} API, 
> {{RemoteBlobProcessor#shouldFetchBinary}} relies on exceptions to implement 
> part of its logic. While this is a bad development practice, it was the only 
> way to cope with in-memory binary IDs without spending excessive amounts of 
> network and CPU. To Improve the transparency of the system, 
> {{RemoteBlobProcessor}} should print a message at WARN level every time it 
> swallows an exception.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-8146) oak-run support for inspecting/modifying clusterNodeInfo

[Marcel Reutegger (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812465#comment-16812465
 ] 

Marcel Reutegger commented on OAK-8146:
---

I like the layout of the list mode. The CREATED column is not useful and prints 
the current date for all entries. It looks like 
ClusterNodeInfoDocument.getCreated() is a bit misleading and I'm even wondering 
if it should be removed.

What do you think about removing the need to add {{list}} to the command to get 
the entries? It would be the default and the command could have a --raw option. 
As you can see, I'd also be in favour of using proper options. I think that 
requires extending {{Utils.NodeStoreOptions}} similar to how the 
{{RevisionsCommand}} does it.

As requested by Jörg, we could make the output parsable in the raw mode, e.g. 
by writing proper JSON.

> oak-run support for inspecting/modifying clusterNodeInfo
> 
>
> Key: OAK-8146
> URL: https://issues.apache.org/jira/browse/OAK-8146
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: documentmk, run
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Attachments: OAK-8146.diff, OAK-8146.diff
>
>
> - readable dump of cluster node info entries
> - command to purge selected entries



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo

[Christian Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812473#comment-16812473
 ] 

Christian Schneider commented on OAK-6880:
--

Thanks .. this indeed might point to the root of the problem. My local pom does 
not contain the repository section. So it seems I got this broken solr-parent 
from somewhere.

Now the question is, where it came from (Adobe artifactory comes to mind). 

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-8203) Build Jackrabbit Oak #2070 failed

[Hudson (JIRA)]

Hudson created OAK-8203:
---

 Summary: Build Jackrabbit Oak #2070 failed
 Key: OAK-8203
 URL: https://issues.apache.org/jira/browse/OAK-8203
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: continuous integration
Reporter: Hudson


No description is provided

The build Jackrabbit Oak #2070 has failed.
First failed run: [Jackrabbit Oak 
#2070|https://builds.apache.org/job/Jackrabbit%20Oak/2070/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/2070/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-8203) Build Jackrabbit Oak #2070 failed

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812506#comment-16812506
 ] 

Hudson commented on OAK-8203:
-

Build is still failing.
Failed run: [Jackrabbit Oak 
#2071|https://builds.apache.org/job/Jackrabbit%20Oak/2071/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/2071/console]

> Build Jackrabbit Oak #2070 failed
> -
>
> Key: OAK-8203
> URL: https://issues.apache.org/jira/browse/OAK-8203
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #2070 has failed.
> First failed run: [Jackrabbit Oak 
> #2070|https://builds.apache.org/job/Jackrabbit%20Oak/2070/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/2070/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-8146) oak-run support for inspecting/modifying clusterNodeInfo

[Marcel Reutegger (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Reutegger updated OAK-8146:
--
Attachment: OAK-8146-1.patch

> oak-run support for inspecting/modifying clusterNodeInfo
> 
>
> Key: OAK-8146
> URL: https://issues.apache.org/jira/browse/OAK-8146
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: documentmk, run
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Attachments: OAK-8146-1.patch, OAK-8146.diff, OAK-8146.diff
>
>
> - readable dump of cluster node info entries
> - command to purge selected entries



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-8146) oak-run support for inspecting/modifying clusterNodeInfo

[Marcel Reutegger (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812522#comment-16812522
 ] 

Marcel Reutegger commented on OAK-8146:
---

Something like this: [^OAK-8146-1.patch]

Manipulating entries could later be added with new options.

> oak-run support for inspecting/modifying clusterNodeInfo
> 
>
> Key: OAK-8146
> URL: https://issues.apache.org/jira/browse/OAK-8146
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: documentmk, run
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Attachments: OAK-8146-1.patch, OAK-8146.diff, OAK-8146.diff
>
>
> - readable dump of cluster node info entries
> - command to purge selected entries



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812561#comment-16812561
 ] 

Robert Munteanu commented on OAK-6880:
--

{code}$ grep -ce repository solr-parent-5.5.5.pom
0
$ cat solr-parent-5.5.5.pom.sha1 
aa3b35c3527c2a846d40f4c292d82e8a3ae0d5b7
{code}

Using that SHA1 for a Maven central returns 0 hits: 
https://search.maven.org/search?q=1:aa3b35c3527c2a846d40f4c292d82e8a3ae0d5b7 . 
Searching for another artifact by SHA works, so the search is correct: 
https://search.maven.org/search?q=1:bba42037edb3c62f62900812e62b66eca2c61d4b .

I have the 'broken' artifact locally as well but not sure where it's coming 
from. I checked the Adobe artifactory instance but only found the 'vanilla' 
solr-parent-5.5.5.pom, cached from Maven central.

BTW, this is precisely why I dislike managing {{}} elements in the 
project pom.xml .

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812566#comment-16812566
 ] 

Robert Munteanu commented on OAK-6880:
--

... however, there is reason to believe Artifactory is involved. In the [JFrog 
virtual repositories 
documentation|https://www.jfrog.com/confluence/display/RTF/Virtual+Repositories#VirtualRepositories-Maven,Gradle,IvyandSBTRepositories]
 it is documented that Maven repositories can configured to remove all 
{{}} elements.

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812569#comment-16812569
 ] 

Robert Munteanu commented on OAK-6880:
--

It seems that we would be able to exclude unexpected Maven artifacts using a 
custom enforcer rule, see

https://stackoverflow.com/questions/14214406/how-to-enforce-a-strict-maven-dependency-policy-dependency-chain-attack

So we could revert the change and validate that the artifact is strictly the 
upstream one. This would make the builds reproducible and clearly state the 
reason for failure.

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812571#comment-16812571
 ] 

Robert Munteanu commented on OAK-6880:
--

... ( I seem to be live-streaming this, sorry ).

I discovered that when trying to access the solr-parent artifact from the 
Artifactory UI, the pom.xml is passed through unchanged from Central. 
_However_, when accessing through the virtual repository that I have configured 
for development the pom is rewritten.

Therefore I think that the solution to add the repository reference to Oak is 
the wrong one and suggest to roll back that change. Instead, we should make 
sure that we use the right solr parent pom.

Thoughts [~edivad]?

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (OAK-6880) Build fails on a fresh m2 repo

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu reopened OAK-6880:
--

Reopening as we have additional information and would like to pursue other 
solutions.

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812615#comment-16812615
 ] 

Julian Reschke commented on OAK-6880:
-

{quote}Therefore I think that the solution to add the repository reference to 
Oak is the wrong one and suggest to roll back that change
{quote}

I did that last week...

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812748#comment-16812748
 ] 

Robert Munteanu commented on OAK-6880:
--

Oh, missed that, sorry [~reschke].

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-8186) Create API in OAK for file access to binaries in the repository.

[Ruben Reusser (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ruben Reusser updated OAK-8186:
---
Attachment: fileCopyTest-0.0.1-SNAPSHOT.jar

> Create API in OAK for file access to binaries in the repository.
> 
>
> Key: OAK-8186
> URL: https://issues.apache.org/jira/browse/OAK-8186
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>Reporter: Henry Saginor
>Priority: Major
> Attachments: OAK File Access.jpg, fileCopyTest-0.0.1-SNAPSHOT.jar
>
>
> To get file access applications normally write binaries to temp files. It 
> would be nice if an API existed to get file access directly from OAK. This 
> might also meet some use cases documented at 
> [https://wiki.apache.org/jackrabbit/JCR%20Binary%20Usecase]
> Suggested API and implementation can be found here [1]. Also, see attached 
> diagram [2].
> I can create a patch if I can get some feedback. Note that suggested API 
> makes it explicit that a temp file is created. I am not sure if direct access 
> to files in datasore would be safe. But I am open to suggestions.
> [1]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/FileReferencable.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReference.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReferenceProvider.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/FileDSBlobTempFileReference.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/DataStoreBlobStore.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentBlob.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/value/jcr/BinaryImpl.java]
> [2]
> !OAK File Access.jpg!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-8186) Create API in OAK for file access to binaries in the repository.

[Ruben Reusser (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ruben Reusser updated OAK-8186:
---
Attachment: FileCopyTest3.java

> Create API in OAK for file access to binaries in the repository.
> 
>
> Key: OAK-8186
> URL: https://issues.apache.org/jira/browse/OAK-8186
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>Reporter: Henry Saginor
>Priority: Major
> Attachments: FileCopyTest3.java, OAK File Access.jpg, 
> fileCopyTest-0.0.1-SNAPSHOT.jar
>
>
> To get file access applications normally write binaries to temp files. It 
> would be nice if an API existed to get file access directly from OAK. This 
> might also meet some use cases documented at 
> [https://wiki.apache.org/jackrabbit/JCR%20Binary%20Usecase]
> Suggested API and implementation can be found here [1]. Also, see attached 
> diagram [2].
> I can create a patch if I can get some feedback. Note that suggested API 
> makes it explicit that a temp file is created. I am not sure if direct access 
> to files in datasore would be safe. But I am open to suggestions.
> [1]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/FileReferencable.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReference.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReferenceProvider.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/FileDSBlobTempFileReference.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/DataStoreBlobStore.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentBlob.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/value/jcr/BinaryImpl.java]
> [2]
> !OAK File Access.jpg!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-8186) Create API in OAK for file access to binaries in the repository.

[Ruben Reusser (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812857#comment-16812857
 ] 

Ruben Reusser commented on OAK-8186:


[~mduerig] [~mattvryan] depending on the size of the file one copies the 
performance differs. Attached is a test jar file you can run to perform a test
{code:java}
java -jar fileCopyTest-0.0.1-SNAPSHOT.jar 100 100 filescopy
{code}
you can use filescopy (uses Files.copy(path, path)) or stream (uses apache 
commons IOUtils.copy(stream, stream)

tool at [2], java class used for testing at [3]

You can see that once the file reaches 1MB the Files.copy performs better. 

test result linux, ssd drive: 
{code}
$ java -jar fileCopyTest-0.0.1-SNAPSHOT.jar 1 100 stream
run:0,100M,1.bin,1.0.bin,91215443ns,91ms
stats:
average: 70ms
total: 6936ms
$ java -jar fileCopyTest-0.0.1-SNAPSHOT.jar 1 100 filescopy
run:0,100M,1.bin,1.0.bin,64425831ns,64ms
stats:
average: 57ms
total: 5623ms
{code}

test result windows, old school drive: 
{code}
>java -jar fileCopyTest-0.0.1-SNAPSHOT.jar 1 100 stream
run:0,100M,1.bin,1.0.bin,148289264ns,148ms
stats:
average: 142ms
total: 13931ms

>java -jar fileCopyTest-0.0.1-SNAPSHOT.jar 1 100 filescopy
run:0,100M,1.bin,1.0.bin,44045122ns,44ms
stats:
average: 42ms
total: 4144ms
{code}

test command options:
{code:java}
fct[verbose]
{code}

note: jackrabbit uses temporary files in jackrabbit-vault after a certain size 
(1MB) at [1]

[1] 
https://github.com/apache/jackrabbit-filevault/blob/6df76ba4a45316a84ec1cd10636296d191a82260/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/ZipStreamArchive.java#L249
[2] 
https://issues.apache.org/jira/secure/attachment/12965256/fileCopyTest-0.0.1-SNAPSHOT.jar
[3] https://issues.apache.org/jira/secure/attachment/12965257/FileCopyTest3.java

> Create API in OAK for file access to binaries in the repository.
> 
>
> Key: OAK-8186
> URL: https://issues.apache.org/jira/browse/OAK-8186
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>Reporter: Henry Saginor
>Priority: Major
> Attachments: FileCopyTest3.java, OAK File Access.jpg, 
> fileCopyTest-0.0.1-SNAPSHOT.jar
>
>
> To get file access applications normally write binaries to temp files. It 
> would be nice if an API existed to get file access directly from OAK. This 
> might also meet some use cases documented at 
> [https://wiki.apache.org/jackrabbit/JCR%20Binary%20Usecase]
> Suggested API and implementation can be found here [1]. Also, see attached 
> diagram [2].
> I can create a patch if I can get some feedback. Note that suggested API 
> makes it explicit that a temp file is created. I am not sure if direct access 
> to files in datasore would be safe. But I am open to suggestions.
> [1]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/FileReferencable.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReference.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReferenceProvider.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/FileDSBlobTempFileReference.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/DataStoreBlobStore.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentBlob.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/value/jcr/BinaryImpl.java]
> [2]
> !OAK File Access.jpg!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-8204) OutOfMemoryError: create nodes

[zhouxu (JIRA)]

zhouxu created OAK-8204:
---

 Summary: OutOfMemoryError: create nodes
 Key: OAK-8204
 URL: https://issues.apache.org/jira/browse/OAK-8204
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: core
Affects Versions: 1.10.2
Reporter: zhouxu


Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceede
d
 at java.lang.AbstractStringBuilder.(AbstractStringBuilder.java:68)

at java.lang.StringBuilder.(StringBuilder.java:101)
 at org.apache.jackrabbit.oak.commons.PathUtils.concat(PathUtils.java:318
)
 at org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.getChild
NodeDoc(DocumentNodeState.java:507)
 at org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.hasChild
Node(DocumentNodeState.java:256)
 at org.apache.jackrabbit.oak.plugins.memory.MutableNodeState.setChildNod
e(MutableNodeState.java:111)
 at org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setChildNo
de(MemoryNodeBuilder.java:343)
 at org.apache.jackrabbit.oak.plugins.document.AbstractDocumentNodeBuilde
r.setChildNode(AbstractDocumentNodeBuilder.java:56)
 at org.apache.jackrabbit.oak.spi.state.ApplyDiff.childNodeAdded(ApplyDif
f.java:80)
 at org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAga
instBaseState(ModifiedNodeState.java:412)
 at org.apache.jackrabbit.oak.spi.state.ApplyDiff.childNodeChanged(ApplyD
iff.java:87)
 at org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAga
instBaseState(ModifiedNodeState.java:416)
 at org.apache.jackrabbit.oak.spi.state.ApplyDiff.childNodeChanged(ApplyD
iff.java:87)
 at org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAga
instBaseState(ModifiedNodeState.java:416)
 at org.apache.jackrabbit.oak.spi.state.ApplyDiff.childNodeChanged(ApplyD
iff.java:87)
 at org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAga
instBaseState(ModifiedNodeState.java:416)
 at org.apache.jackrabbit.oak.plugins.document.ModifiedDocumentNodeState.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-8204) OutOfMemoryError: create nodes

[zhouxu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-8204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

zhouxu updated OAK-8204:

Issue Type: Bug  (was: Improvement)

> OutOfMemoryError: create nodes
> --
>
> Key: OAK-8204
> URL: https://issues.apache.org/jira/browse/OAK-8204
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.10.2
>Reporter: zhouxu
>Priority: Major
>
> Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit 
> exceede
> d
>  at java.lang.AbstractStringBuilder.(AbstractStringBuilder.java:68)
> at java.lang.StringBuilder.(StringBuilder.java:101)
>  at org.apache.jackrabbit.oak.commons.PathUtils.concat(PathUtils.java:318
> )
>  at org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.getChild
> NodeDoc(DocumentNodeState.java:507)
>  at org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.hasChild
> Node(DocumentNodeState.java:256)
>  at org.apache.jackrabbit.oak.plugins.memory.MutableNodeState.setChildNod
> e(MutableNodeState.java:111)
>  at org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setChildNo
> de(MemoryNodeBuilder.java:343)
>  at org.apache.jackrabbit.oak.plugins.document.AbstractDocumentNodeBuilde
> r.setChildNode(AbstractDocumentNodeBuilder.java:56)
>  at org.apache.jackrabbit.oak.spi.state.ApplyDiff.childNodeAdded(ApplyDif
> f.java:80)
>  at org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAga
> instBaseState(ModifiedNodeState.java:412)
>  at org.apache.jackrabbit.oak.spi.state.ApplyDiff.childNodeChanged(ApplyD
> iff.java:87)
>  at org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAga
> instBaseState(ModifiedNodeState.java:416)
>  at org.apache.jackrabbit.oak.spi.state.ApplyDiff.childNodeChanged(ApplyD
> iff.java:87)
>  at org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAga
> instBaseState(ModifiedNodeState.java:416)
>  at org.apache.jackrabbit.oak.spi.state.ApplyDiff.childNodeChanged(ApplyD
> iff.java:87)
>  at org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAga
> instBaseState(ModifiedNodeState.java:416)
>  at org.apache.jackrabbit.oak.plugins.document.ModifiedDocumentNodeState.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (OAK-6880) Build fails on a fresh m2 repo

[Julian Reschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke resolved OAK-6880.
-
Resolution: Not A Problem

Closing again.

People who see this should check whether their local copy of the solr-parent 
5.5.5 pom is correct.

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-8167) With uneven distribution of ACL restriction across facet labels statistical facet count become too inaccurate

[angela (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-8167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16813047#comment-16813047
 ] 

angela commented on OAK-8167:
-

[~catholicon], the severity of the vulnerability depends on the sensitivity of 
the data exposed. For example, if it is PII relevant the leak is critical and 
may come with legal actions. So, you might get prepared for serious 
repercussion. I would definitely recommend the warning highlighting the 
information leakage and also log it as warning.

> With uneven distribution of ACL restriction across facet labels statistical 
> facet count become too inaccurate
> -
>
> Key: OAK-8167
> URL: https://issues.apache.org/jira/browse/OAK-8167
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: lucene, query
>Affects Versions: 1.6.16
>Reporter: Kelvin Xu
>Priority: Major
>  Labels: vulnerability
>
> With the statistical mode, facet count is updated proportionally to the 
> percentage of accessible samples, which works for secured contents scattered 
> across different facets. For edge case where the whole facet (results) is not 
> accessible, the count still shows a number after the sampling percent is 
> applied. Even if the number is small, user experience is 
> misleading/inaccurate as nothing would return when the facet is clicked 
> (applied as a query condition).
> For example, a ACLs/CUGs guarded "private" folder, in which all the assets 
> are tagged with the same facet value. Non authorized user may still see this 
> facet with a count but gets nothing when clicking on the facet.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)