[jira] [Commented] (JCR-3826) AbstractPrincipalProvider cachesize is not configurable
[ https://issues.apache.org/jira/browse/JCR-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14185325#comment-14185325 ] Manfred Baedke commented on JCR-3826: - Fixed in trunk with revision 1634584: LoginModule configurations without an explicitly configured PrincipalProvider class name will now by applied to the DefaultPrincipalProvider. AbstractPrincipalProvider cachesize is not configurable --- Key: JCR-3826 URL: https://issues.apache.org/jira/browse/JCR-3826 Project: Jackrabbit Content Repository Issue Type: Improvement Components: config Reporter: Manfred Baedke Assignee: Manfred Baedke Priority: Minor AbstractPrincipalProvider has a property cacheMaxSize, but it's impossible to configure it for the default implementations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCR-3826) AbstractPrincipalProvider cachesize is not configurable
[ https://issues.apache.org/jira/browse/JCR-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated JCR-3826: Fix Version/s: 2.9.1 AbstractPrincipalProvider cachesize is not configurable --- Key: JCR-3826 URL: https://issues.apache.org/jira/browse/JCR-3826 Project: Jackrabbit Content Repository Issue Type: Improvement Components: config Reporter: Manfred Baedke Assignee: Manfred Baedke Priority: Minor Fix For: 2.9.1 AbstractPrincipalProvider has a property cacheMaxSize, but it's impossible to configure it for the default implementations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCRVLT-68) Wrong JAVA_HOME default location for OSX Yosemite
Roland Schaer created JCRVLT-68:
---
Summary: Wrong JAVA_HOME default location for OSX Yosemite
Key: JCRVLT-68
URL: https://issues.apache.org/jira/browse/JCRVLT-68
Project: Jackrabbit FileVault
Issue Type: Bug
Affects Versions: 3.1.6
Environment: OSX Yosemite
Reporter: Roland Schaer
Priority: Minor
On OSX Yosemite the fallback {{JAVA_HOME}} variable with the value
{{/System/Library/Frameworks/JavaVM.framework/Versions/${JAVA_VERSION}/Home}}
is not applicable anymore in the shell scripts. Apple is recommending using
{{/usr/libexec/java_home}} with the {{-v}} option if necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCRVLT-68) Wrong JAVA_HOME default location for OSX Yosemite
[
https://issues.apache.org/jira/browse/JCRVLT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roland Schaer updated JCRVLT-68:
Description: On OSX Yosemite the fallback {{JAVA_HOME}} variable with the
value
{{/System/Library/Frameworks/JavaVM.framework/Versions/$\{JAVA_VERSION}/Home}}
is not applicable anymore in the shell scripts. Apple is recommending using
{{/usr/libexec/java_home}} with the {{-v}} option if necessary. (was: On OSX
Yosemite the fallback {{JAVA_HOME}} variable with the value
{{/System/Library/Frameworks/JavaVM.framework/Versions/${JAVA_VERSION}/Home}}
is not applicable anymore in the shell scripts. Apple is recommending using
{{/usr/libexec/java_home}} with the {{-v}} option if necessary.)
Wrong JAVA_HOME default location for OSX Yosemite
-
Key: JCRVLT-68
URL: https://issues.apache.org/jira/browse/JCRVLT-68
Project: Jackrabbit FileVault
Issue Type: Bug
Affects Versions: 3.1.6
Environment: OSX Yosemite
Reporter: Roland Schaer
Priority: Minor
On OSX Yosemite the fallback {{JAVA_HOME}} variable with the value
{{/System/Library/Frameworks/JavaVM.framework/Versions/$\{JAVA_VERSION}/Home}}
is not applicable anymore in the shell scripts. Apple is recommending using
{{/usr/libexec/java_home}} with the {{-v}} option if necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JCR-3826) AbstractPrincipalProvider cachesize is not configurable
[ https://issues.apache.org/jira/browse/JCR-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke resolved JCR-3826. - Resolution: Fixed AbstractPrincipalProvider cachesize is not configurable --- Key: JCR-3826 URL: https://issues.apache.org/jira/browse/JCR-3826 Project: Jackrabbit Content Repository Issue Type: Improvement Components: config Reporter: Manfred Baedke Assignee: Manfred Baedke Priority: Minor Fix For: 2.9.1 AbstractPrincipalProvider has a property cacheMaxSize, but it's impossible to configure it for the default implementations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jackrabbit-trunk - Build # 2254 - Failure
The Apache Jenkins build system has built Jackrabbit-trunk (build #2254) Status: Failure Check console output at https://builds.apache.org/job/Jackrabbit-trunk/2254/ to view the results.
[jira] [Commented] (JCRVLT-68) Wrong JAVA_HOME default location for OSX Yosemite
[
https://issues.apache.org/jira/browse/JCRVLT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14185621#comment-14185621
]
Roland Schaer commented on JCRVLT-68:
-
Possible fix: https://github.com/apache/jackrabbit-filevault/pull/2
Wrong JAVA_HOME default location for OSX Yosemite
-
Key: JCRVLT-68
URL: https://issues.apache.org/jira/browse/JCRVLT-68
Project: Jackrabbit FileVault
Issue Type: Bug
Affects Versions: 3.1.6
Environment: OSX Yosemite
Reporter: Roland Schaer
Priority: Minor
On OSX Yosemite the fallback {{JAVA_HOME}} variable with the value
{{/System/Library/Frameworks/JavaVM.framework/Versions/$\{JAVA_VERSION}/Home}}
is not applicable anymore in the shell scripts. Apple is recommending using
{{/usr/libexec/java_home}} with the {{-v}} option if necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JCRVLT-68) Wrong JAVA_HOME default location for OSX Yosemite
[
https://issues.apache.org/jira/browse/JCRVLT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved JCRVLT-68.
Resolution: Fixed
Fix Version/s: 3.1.8
thanks. applied pull request in r1634672
Wrong JAVA_HOME default location for OSX Yosemite
-
Key: JCRVLT-68
URL: https://issues.apache.org/jira/browse/JCRVLT-68
Project: Jackrabbit FileVault
Issue Type: Bug
Affects Versions: 3.1.6
Environment: OSX Yosemite
Reporter: Roland Schaer
Priority: Minor
Fix For: 3.1.8
On OSX Yosemite the fallback {{JAVA_HOME}} variable with the value
{{/System/Library/Frameworks/JavaVM.framework/Versions/$\{JAVA_VERSION}/Home}}
is not applicable anymore in the shell scripts. Apple is recommending using
{{/usr/libexec/java_home}} with the {{-v}} option if necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JCRVLT-63) DocViewSAXImporter relies on implementation detail wrt authorizable Id
[ https://issues.apache.org/jira/browse/JCRVLT-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra resolved JCRVLT-63. Resolution: Fixed Fix Version/s: 3.1.8 applied patchin r1634691. thanks. DocViewSAXImporter relies on implementation detail wrt authorizable Id -- Key: JCRVLT-63 URL: https://issues.apache.org/jira/browse/JCRVLT-63 Project: Jackrabbit FileVault Issue Type: Bug Reporter: angela Assignee: Tobias Bocanegra Fix For: 3.1.8 Attachments: JCRVLT-63.patch upon user/group import the DocViewSAXImporter relies on the jackrabbit 2.x implementation that the authorizable id is encoded in the name of the corresponding node. since oak 1.0 however this can be customized and there is no guarantee that the node name reveals the authorizable id (see http://jackrabbit.apache.org/oak/docs/security/user.html). in order to keep fvault compatible with oak this should be fixed. proposed (but untested) patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCRVLT-63) DocViewSAXImporter relies on implementation detail wrt authorizable Id
[ https://issues.apache.org/jira/browse/JCRVLT-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated JCRVLT-63: --- Fix Version/s: (was: 3.1.8) 3.1.10 DocViewSAXImporter relies on implementation detail wrt authorizable Id -- Key: JCRVLT-63 URL: https://issues.apache.org/jira/browse/JCRVLT-63 Project: Jackrabbit FileVault Issue Type: Bug Reporter: angela Assignee: Tobias Bocanegra Fix For: 3.1.10 Attachments: JCRVLT-63.patch upon user/group import the DocViewSAXImporter relies on the jackrabbit 2.x implementation that the authorizable id is encoded in the name of the corresponding node. since oak 1.0 however this can be customized and there is no guarantee that the node name reveals the authorizable id (see http://jackrabbit.apache.org/oak/docs/security/user.html). in order to keep fvault compatible with oak this should be fixed. proposed (but untested) patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCRVLT-68) Wrong JAVA_HOME default location for OSX Yosemite
[
https://issues.apache.org/jira/browse/JCRVLT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated JCRVLT-68:
---
Fix Version/s: (was: 3.1.8)
3.1.10
Wrong JAVA_HOME default location for OSX Yosemite
-
Key: JCRVLT-68
URL: https://issues.apache.org/jira/browse/JCRVLT-68
Project: Jackrabbit FileVault
Issue Type: Bug
Affects Versions: 3.1.6
Environment: OSX Yosemite
Reporter: Roland Schaer
Priority: Minor
Fix For: 3.1.10
On OSX Yosemite the fallback {{JAVA_HOME}} variable with the value
{{/System/Library/Frameworks/JavaVM.framework/Versions/$\{JAVA_VERSION}/Home}}
is not applicable anymore in the shell scripts. Apple is recommending using
{{/usr/libexec/java_home}} with the {{-v}} option if necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (JCRVLT-52) Set maven-compiler-plugin target/source version to 1.6
[ https://issues.apache.org/jira/browse/JCRVLT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra closed JCRVLT-52. -- Set maven-compiler-plugin target/source version to 1.6 -- Key: JCRVLT-52 URL: https://issues.apache.org/jira/browse/JCRVLT-52 Project: Jackrabbit FileVault Issue Type: Task Affects Versions: 3.1.2 Reporter: Robert Munteanu Fix For: 3.1.8 Attachments: JCRVLT-52-1.diff The parent pom sets the maven-compiler-plugin version source/target version to 1.5. However, Java 6 specific methods are already used, such as * String#isEmpty * IOException(String, Exception) * TreeMap.firstEntry The source/target versions should be set to 1.6 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (JCRVLT-56) Add support for oak system users
[ https://issues.apache.org/jira/browse/JCRVLT-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra closed JCRVLT-56. -- Add support for oak system users Key: JCRVLT-56 URL: https://issues.apache.org/jira/browse/JCRVLT-56 Project: Jackrabbit FileVault Issue Type: Task Reporter: angela Assignee: Tobias Bocanegra Fix For: 3.1.8 see JCR-3802 for an initial draft and some related comments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (JCRVLT-55) vlt st should notify the user executed in a directory not under vault control
[
https://issues.apache.org/jira/browse/JCRVLT-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra closed JCRVLT-55.
--
vlt st should notify the user executed in a directory not under vault control
-
Key: JCRVLT-55
URL: https://issues.apache.org/jira/browse/JCRVLT-55
Project: Jackrabbit FileVault
Issue Type: Bug
Affects Versions: 3.1.6
Reporter: Robert Munteanu
Assignee: Tobias Bocanegra
Fix For: 3.1.8
See the following sequence of commands:
{noformat}
$ vlt st
$ vlt up
[ERROR] update: org.apache.jackrabbit.vault.vlt.VltException: Directory is
not under vault control.
{noformat}
I would've expected the vlt st command to return the same error, or at least
a warning
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (JCRVLT-54) [vault-rcp] Allow single task retrieval
[
https://issues.apache.org/jira/browse/JCRVLT-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra closed JCRVLT-54.
--
[vault-rcp] Allow single task retrieval
---
Key: JCRVLT-54
URL: https://issues.apache.org/jira/browse/JCRVLT-54
Project: Jackrabbit FileVault
Issue Type: Improvement
Affects Versions: 3.1
Reporter: Honwai Wong
Priority: Minor
Fix For: 3.1.8
It'd be great if the {{RcpServlet}} could provide a method to retrieve a
single task in addition to always return the complete list of tasks.
I started to build a UI on top of the vault-rcp REST API sometime ago and
would like to target individual tasks to update their current status.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JCRVLT-69) Packages with multi-node memberships are not merged correctly
Tobias Bocanegra created JCRVLT-69: -- Summary: Packages with multi-node memberships are not merged correctly Key: JCRVLT-69 URL: https://issues.apache.org/jira/browse/JCRVLT-69 Project: Jackrabbit FileVault Issue Type: Bug Reporter: Tobias Bocanegra -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCRVLT-69) Packages with multi-node memberships are not merged correctly
[
https://issues.apache.org/jira/browse/JCRVLT-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14186026#comment-14186026
]
Tobias Bocanegra commented on JCRVLT-69:
If a package contains multi-node memberships that should be merged into
existing content, then the DocViewSaxImporter might not add them properly.
suggest: Create own {{DocViewAdapter}} for Groups
Packages with multi-node memberships are not merged correctly
-
Key: JCRVLT-69
URL: https://issues.apache.org/jira/browse/JCRVLT-69
Project: Jackrabbit FileVault
Issue Type: Bug
Reporter: Tobias Bocanegra
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCRVLT-67) rep:authorizableId might be removed on package install causing error in oak
[
https://issues.apache.org/jira/browse/JCRVLT-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14186083#comment-14186083
]
Tobias Bocanegra commented on JCRVLT-67:
after a temporary fix in oak, now get:
{noformat}
2022 [main] ERROR org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage -
Error during install.
javax.jcr.nodetype.ConstraintViolationException: OakConstraint0022:
Authorizable property rep:authorizableId may not be altered after user/group
creation.
at
org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225)
at
org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212)
{noformat}
rep:authorizableId might be removed on package install causing error in oak
---
Key: JCRVLT-67
URL: https://issues.apache.org/jira/browse/JCRVLT-67
Project: Jackrabbit FileVault
Issue Type: Bug
Reporter: Tobias Bocanegra
Assignee: Tobias Bocanegra
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JCRVLT-66) Updating an exiting authorizable does not work if on different path (mode=merge)
[ https://issues.apache.org/jira/browse/JCRVLT-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra resolved JCRVLT-66. Resolution: Fixed Fix Version/s: 3.1.10 fixed in r1634753 Updating an exiting authorizable does not work if on different path (mode=merge) Key: JCRVLT-66 URL: https://issues.apache.org/jira/browse/JCRVLT-66 Project: Jackrabbit FileVault Issue Type: Bug Reporter: Tobias Bocanegra Assignee: Tobias Bocanegra Fix For: 3.1.10 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCRVLT-67) rep:authorizableId might be removed on package install causing error in oak
[ https://issues.apache.org/jira/browse/JCRVLT-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra resolved JCRVLT-67. Resolution: Fixed Fix Version/s: 3.1.10 fixed in r1634753 rep:authorizableId might be removed on package install causing error in oak --- Key: JCRVLT-67 URL: https://issues.apache.org/jira/browse/JCRVLT-67 Project: Jackrabbit FileVault Issue Type: Bug Reporter: Tobias Bocanegra Assignee: Tobias Bocanegra Fix For: 3.1.10 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCRVLT-64) Nodes that have a user parent are not installed if they are in the same .content.xml as their parent
[
https://issues.apache.org/jira/browse/JCRVLT-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14186123#comment-14186123
]
Tobias Bocanegra commented on JCRVLT-64:
btw: the filter.xml would cause deletion of all child nodes of the profile
node. I don't think this is intended:
{noformat}
?xml version=1.0 encoding=UTF-8?
workspaceFilter version=1.0
filter root=/home/users/n/newuser/profile
include pattern=/home/users/n/newuser/profile/
/filter
/workspaceFilter
{noformat}
Nodes that have a user parent are not installed if they are in the same
.content.xml as their parent
Key: JCRVLT-64
URL: https://issues.apache.org/jira/browse/JCRVLT-64
Project: Jackrabbit FileVault
Issue Type: Bug
Reporter: Marius Petria
Attachments: newuser.zip, profile.zip
An artifact for an user node that also contains another child node is not
installed correctly. Only the user is installed and not the profile.
{code}
jcr:root xmlns:sling=http://sling.apache.org/jcr/sling/1.0;
xmlns:jcr=http://www.jcp.org/jcr/1.0;
xmlns:nt=http://www.jcp.org/jcr/nt/1.0; xmlns:rep=internal
jcr:mixinTypes=[rep:AccessControllable]
jcr:primaryType=rep:User
jcr:uuid=0354d89c-28ec-399c-80d3-cb2d094cf093
rep:authorizableId=newuser
rep:password=\{SHA-256}8628e1f645c2073a-1000-9db3a1f8cddca62bbde8aae52832378c061498598ef833aaa209c1c836704db0
rep:principalName=newuser
profile
jcr:primaryType=nt:unstructured
sling:resourceType=cq/security/components/profile
givenName=MM
photos/
/profile
/jcr:root
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (JCRVLT-64) Nodes that have a user parent are not installed if they are in the same .content.xml as their parent
[
https://issues.apache.org/jira/browse/JCRVLT-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra reassigned JCRVLT-64:
--
Assignee: Tobias Bocanegra
Nodes that have a user parent are not installed if they are in the same
.content.xml as their parent
Key: JCRVLT-64
URL: https://issues.apache.org/jira/browse/JCRVLT-64
Project: Jackrabbit FileVault
Issue Type: Bug
Reporter: Marius Petria
Assignee: Tobias Bocanegra
Attachments: newuser.zip, profile.zip
An artifact for an user node that also contains another child node is not
installed correctly. Only the user is installed and not the profile.
{code}
jcr:root xmlns:sling=http://sling.apache.org/jcr/sling/1.0;
xmlns:jcr=http://www.jcp.org/jcr/1.0;
xmlns:nt=http://www.jcp.org/jcr/nt/1.0; xmlns:rep=internal
jcr:mixinTypes=[rep:AccessControllable]
jcr:primaryType=rep:User
jcr:uuid=0354d89c-28ec-399c-80d3-cb2d094cf093
rep:authorizableId=newuser
rep:password=\{SHA-256}8628e1f645c2073a-1000-9db3a1f8cddca62bbde8aae52832378c061498598ef833aaa209c1c836704db0
rep:principalName=newuser
profile
jcr:primaryType=nt:unstructured
sling:resourceType=cq/security/components/profile
givenName=MM
photos/
/profile
/jcr:root
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JCR-3828) BufferedDataStore Implementation
BELUGA BEHR created JCR-3828: Summary: BufferedDataStore Implementation Key: JCR-3828 URL: https://issues.apache.org/jira/browse/JCR-3828 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-data Reporter: BELUGA BEHR Priority: Trivial Attachments: BufferedDataStore.java, FileDataStoreMarkWalker.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCR-3828) BufferedDataStore Implementation
[ https://issues.apache.org/jira/browse/JCR-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated JCR-3828: - Attachment: FileDataStoreMarkWalker.java BufferedDataStore.java BufferedDataStore Implementation Key: JCR-3828 URL: https://issues.apache.org/jira/browse/JCR-3828 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-data Reporter: BELUGA BEHR Priority: Trivial Attachments: BufferedDataStore.java, FileDataStoreMarkWalker.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCRVLT-65) Packages of authorizable content rely on a stable authorizable path
[ https://issues.apache.org/jira/browse/JCRVLT-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14186154#comment-14186154 ] Tobias Bocanegra commented on JCRVLT-65: added test case in r1634757 Packages of authorizable content rely on a stable authorizable path --- Key: JCRVLT-65 URL: https://issues.apache.org/jira/browse/JCRVLT-65 Project: Jackrabbit FileVault Issue Type: Bug Reporter: Tobias Bocanegra assume a package with content in /home/users/t/toby/profile_public and a respective workspace filter just for the profile_public content. if this package is to be installed in a repository, where the authorizables path is different, the installation will fail or produce the wrong results. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCR-3828) BufferedDataStore Implementation
[ https://issues.apache.org/jira/browse/JCR-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated JCR-3828: - Description: The following implementation features several key changes: 1) Buffer records in memory and discard the buffer if the file is already in the Data Store. This allows for very fast processing of duplicate files with small overhead for files that do not collide. 2) Use of read/write locks so that multiple records can be submitted simultaneously without blocking, but will be blocked if there are deletions occurring. 3) Less synchronization in general. BufferedDataStore Implementation Key: JCR-3828 URL: https://issues.apache.org/jira/browse/JCR-3828 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-data Reporter: BELUGA BEHR Priority: Trivial Attachments: BufferedDataStore.java, FileDataStoreMarkWalker.java The following implementation features several key changes: 1) Buffer records in memory and discard the buffer if the file is already in the Data Store. This allows for very fast processing of duplicate files with small overhead for files that do not collide. 2) Use of read/write locks so that multiple records can be submitted simultaneously without blocking, but will be blocked if there are deletions occurring. 3) Less synchronization in general. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCRVLT-64) Nodes that have a user parent are not installed if they are in the same .content.xml as their parent
[
https://issues.apache.org/jira/browse/JCRVLT-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14186155#comment-14186155
]
Tobias Bocanegra commented on JCRVLT-64:
added test case in r1634757
Nodes that have a user parent are not installed if they are in the same
.content.xml as their parent
Key: JCRVLT-64
URL: https://issues.apache.org/jira/browse/JCRVLT-64
Project: Jackrabbit FileVault
Issue Type: Bug
Reporter: Marius Petria
Assignee: Tobias Bocanegra
Attachments: newuser.zip, profile.zip
An artifact for an user node that also contains another child node is not
installed correctly. Only the user is installed and not the profile.
{code}
jcr:root xmlns:sling=http://sling.apache.org/jcr/sling/1.0;
xmlns:jcr=http://www.jcp.org/jcr/1.0;
xmlns:nt=http://www.jcp.org/jcr/nt/1.0; xmlns:rep=internal
jcr:mixinTypes=[rep:AccessControllable]
jcr:primaryType=rep:User
jcr:uuid=0354d89c-28ec-399c-80d3-cb2d094cf093
rep:authorizableId=newuser
rep:password=\{SHA-256}8628e1f645c2073a-1000-9db3a1f8cddca62bbde8aae52832378c061498598ef833aaa209c1c836704db0
rep:principalName=newuser
profile
jcr:primaryType=nt:unstructured
sling:resourceType=cq/security/components/profile
givenName=MM
photos/
/profile
/jcr:root
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Oak 1.1.2 release
On 24/10/2014 08:29, Davide Giannella wrote: Good morning team, I'm planning to cut the next unstable release next monday PM. There are some unresolved issues. Update where needed and if you need extra time for resolving just let me know. https://issues.apache.org/jira/issues/?jql=project%20%3D%20OAK%20AND%20status%20in%20%28Open%2C%20%22In%20Progress%22%2C%20Reopened%29%20AND%20fixVersion%20%3D%201.1.2 Postponing to this Thursday PM. Cheers Davide
Re: DocumentNodeStore backgroundRead
Hi, Changes from other cluster nodes are detected that way (if a cluster node changes anything, it writes to the root node once a second). Regards, Thomas On 25/10/14 13:08, Julian Reschke julian.resc...@gmx.de wrote: Hi again. I've been looking at what cache misses the RDBDocumentStore gets. It seems that the DocumentNodeStore's background threads run once per second by default. The first thing the backgroundRead does is: String id = Utils.getIdFromPath(/); NodeDocument doc = store.find(Collection.NODES, id, asyncDelay); where asyncDelay is 1000 as well. This causes the find on 0:/ to produce a cache miss, unless there was other activity on that cache entry within the last 1000ms, thus causing a roundtrip to the persistence. Is this really the intention? Best regards, Julian
Re: Does Lucene modifies existing file in an index
To close the thread. With modified testcase [1] the Lucene index file do not get updated. Is this switch from cfs format to storing in separate files is automatic and done by Lucene after index reaches certain size. Or this done something specifically in Oak? This is done because as per default setup Lucene uses following merge policy mergePolicy=[TieredMergePolicy: maxMergeAtOnce=10, maxMergeAtOnceExplicit=30, maxMergedSegmentMB=5120.0, floorSegmentMB=2.0, forceMergeDeletesPctAllowed=10.0, segmentsPerTier=10.0, maxCFSSegmentSizeMB=8.796093022207999E12, noCFSRatio=0.1 i When noCFSRatio crosses 0.1 then CFS file would not be used. Below is the IndexConfig state used to create the index dir=OakDirectory@79a302e9 lockFactory=org.apache.lucene.store.NoLockFactory@183ee75d index= version=4.7.1 1582953 - sarowe - 2014-03-29 00:33:55 matchVersion=LUCENE_47 analyzer=org.apache.jackrabbit.oak.plugins.index.lucene.OakAnalyzer ramBufferSizeMB=16.0 maxBufferedDocs=-1 maxBufferedDeleteTerms=-1 mergedSegmentWarmer=null readerTermsIndexDivisor=1 termIndexInterval=32 delPolicy=org.apache.lucene.index.KeepOnlyLastCommitDeletionPolicy commit=null openMode=CREATE_OR_APPEND similarity=org.apache.lucene.search.similarities.DefaultSimilarity mergeScheduler=org.apache.lucene.index.SerialMergeScheduler@7fe47c41 default WRITE_LOCK_TIMEOUT=1000 writeLockTimeout=1000 codec=Lucene46 infoStream=org.apache.lucene.util.PrintStreamInfoStream mergePolicy=[TieredMergePolicy: maxMergeAtOnce=10, maxMergeAtOnceExplicit=30, maxMergedSegmentMB=5120.0, floorSegmentMB=2.0, forceMergeDeletesPctAllowed=10.0, segmentsPerTier=10.0, maxCFSSegmentSizeMB=8.796093022207999E12, noCFSRatio=0.1 indexerThreadPool=org.apache.lucene.index.ThreadAffinityDocumentsWriterThreadPool@7199d0ff readerPooling=false perThreadHardLimitMB=1945 useCompoundFile=true -- Chetan Mehrotra [1] http://svn.apache.org/r1634504
Re: Reindex and external indexes - Possibility of stale index data
Had a offline chat with Thomas on that and for now creationTime based approach can be used to allow index logic to distinguish between reindex and fresh index. Thomas proposal above was more to avoid large transaction problem where new index would be build side by side. With Lucene this is not a big issue as only binary references constitute state of the unmerged branch. If such an issue is identified later then we can look into implementing above mentioned mechanism Opened OAK-2229 for this Chetan Mehrotra On Tue, Oct 21, 2014 at 3:09 PM, Thomas Mueller muel...@adobe.com wrote: Hi, Yes, that's my point. I wouldn't use MVCC for reindexing the Lucene index. Reindexing is very costly, and I wouldn't do it in one huge, and possibly hours long transaction. * You need to have access to the old and (for readers) the new data (to re-create the index) * Eventually, you want to remove the old data (possibly piece by piece) * You may need to map the structure to a file system, which means separate directories Regards, Thomas On 21/10/14 11:19, Chetan Mehrotra chetan.mehro...@gmail.com wrote: Thanks for the details Thomas! But above model varies from current model which make use of MVCC. The reindex operation triggers removal of :data node in branch and IndexReader always looks for :data node to open the directory on trunk. So while reindex is in progress existing readers make use of the node which is not seen as removed in trunk. What I need is just a way to differentiate index state for a reindex call and that can be managed easily via storing the creation time in the index definition node which works easily with existing logic Chetan Mehrotra On Tue, Oct 21, 2014 at 1:51 PM, Thomas Mueller muel...@adobe.com wrote: Hi, The node doesn't need to be moved, even after multiple reindex operations. Please note index creation is no different from reindex. In both cases, a new index data node is created. So, if an index definition is created: /oak:index/lucene Then the index is being built: /oak:index/lucene/:data_12345 The index is done building (a): /oak:index/lucene/:data_12345/@ready=true Reindexing is started (b): /oak:index/lucene/@reindex=true /oak:index/lucene/:data_12345/@ready=true While reindex is in progress: /oak:index/lucene/@reindex=true /oak:index/lucene/:data_12345/@ready=true /oak:index/lucene/:data_1 When reindex is done (matches a): /oak:index/lucene/:data_1/@ready=true Reindex again is just restart from (b). Regards, Thomas On 21/10/14 10:00, Chetan Mehrotra chetan.mehro...@gmail.com wrote: On Tue, Oct 21, 2014 at 1:18 PM, Thomas Mueller muel...@adobe.com wrote: What we need is a distinction between the old and the new index *data*. Yes and that can be done by storing the index creation time. In the approach you suggested where two different nodes are used and later the nodes are renamed allows the logic to determine that its reindex. Renaming the node would be fine in this case as actual data is stored on filesystem but if it contains actual data then such a move might be costly. For e.g. in copy on read case the index data would be stored in NodeStore and also on file system. Further this is something which each such index implementation would need to follow Instead if we just record the creation time in the index definition node and then allow index impls to make use of that info to distinguish between a reindex and incremental index then that would serve the same purpose Chetan Mehrotra
Re: Getting Started With JackRabbit Oak - A Complete Beginner
I¹m in the same boat as the OP. I¹m also having a hard time getting my head around both the components within oak, but more so, the question of wrapper components that sit on top of the JCR. My apologies for hijacking your thread, but I thought it may help to consolidate related rookie info. Plus, the subject fits exactly. The oak JCR itself is fairly low level and requires a lot of additional infrastructure to provide a functional application. I¹ve looked into some more enterprisey type systems, like alfresco, magnolia, eXo, etc, and they all appear to use the older jackrabbit non-oak version. Are there any more comprehensive apps that are currently using oak as a foundation? Our needs include: - a JCR for binary content, text, pdf, video, audio, etc. All kinds of media files, grouped in a hierarchical fashion. - RBAC for controlling access to content as well as tracking changes by user and providing an audit path - Some way of managing users and permissions - this alone is an argument for using a higher level app than direct jcr coding. - Allowing users direct access to the webDAV view of the repo for content editing, while tracking edits by user and generating events on edit commits. - Some form of workflow management, again, this has been done 1e6 times already. Why re-invent. What¹s available that works with oak/sling? - and of course the push/pull of data into the jcr. This is the primary reason for looking at oak, but it¹s the associated support tasks that are pushing for a more fully functional framework. What are the package blocks people are using with oak? Does everyone use sling? Is that the only option for oak or are there others? thanks in advance. -Bruce From: Michael Dürig mdue...@apache.org Reply-To: oak-dev@jackrabbit.apache.org oak-dev@jackrabbit.apache.org Date: Monday, September 8, 2014 at 1:42 AM To: oak-dev@jackrabbit.apache.org oak-dev@jackrabbit.apache.org Subject: Re: Getting Started With JackRabbit Oak - A Complete Beginner Hi Aman, On 8.9.14 7:44 , Aman Arora wrote: 1. For a complete beginner to start developing on Jackrabbit Oak, we didn't find sufficient resources online. Unfortunately there is currently not much more than the Oak documentation web site at http://jackrabbit.apache.org/oak/docs/, which is still work in progress. Fortunately however, Oak implements the JCR specification. So unless you want to customise Oak, you should be fine with any JCR documentation out there. 2. There was a mismatch between the code listed on your website and the actual implementation. Refer this question asked by me.http://stackoverflow.com/questions/25681933/how-to-create-repository- instance-in-jackrabbit-oak-using-microkernel/25691088#25691088 See my answer http://stackoverflow.com/questions/25681933/how-to-create-repository-insta nce-in-jackrabbit-oak-using-microkernel/25720244#25720244 Michael I would like to have some help on few things: 1. A good documentation or some book/reference to read about the working, components, etc. of Jackrabbit Oak. 2. A starting point to develop a content document library using Jackrabbit Oak. Thanks in advance. Looking forward to your support. Thanks Regards, Aman Arora Software Engineer | EEM -RD Manhattan Associates, India
