[jira] [Commented] (OAK-5051) Document XPath (and SQL-2) syntax as supported by Oak
[ https://issues.apache.org/jira/browse/OAK-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16349807#comment-16349807 ] Chetan Mehrotra commented on OAK-5051: -- bq. I've updated grammar-xpath.md [1] to utilize a doxia macro (part of the same branch) that renders railroads Interesting stuff! > Document XPath (and SQL-2) syntax as supported by Oak > - > > Key: OAK-5051 > URL: https://issues.apache.org/jira/browse/OAK-5051 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > > The JCR 2.0 SQL-2 language is documented at > http://h2database.com/jcr/grammar.html > But extensions to that are not documented. And XPath (as supported by Oak) is > not documented at all. > It would be good to have such a documentation, with examples. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7223) Files could be kept partially in case of disconnection from backends
[ https://issues.apache.org/jira/browse/OAK-7223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-7223: --- Fix Version/s: 1.6.9 > Files could be kept partially in case of disconnection from backends > > > Key: OAK-7223 > URL: https://issues.apache.org/jira/browse/OAK-7223 > Project: Jackrabbit Oak > Issue Type: Bug > Components: blob-plugins >Affects Versions: 1.6.8, 1.8.1 >Reporter: Amit Jain >Assignee: Amit Jain >Priority: Blocker > Fix For: 1.9.0, 1.10, 1.6.9, 1.8.2 > > Attachments: OAK-7223-2.patch, OAK-7223-3.patch, OAK-7223.patch > > > The FileCache#load method needs to clean the files which may have been > downloaded partially in case of errors from backend. This partially > downloaded file should be removed before returning from the method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7223) Files could be kept partially in case of disconnection from backends
[ https://issues.apache.org/jira/browse/OAK-7223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-7223: --- Affects Version/s: 1.6.8 > Files could be kept partially in case of disconnection from backends > > > Key: OAK-7223 > URL: https://issues.apache.org/jira/browse/OAK-7223 > Project: Jackrabbit Oak > Issue Type: Bug > Components: blob-plugins >Affects Versions: 1.6.8, 1.8.1 >Reporter: Amit Jain >Assignee: Amit Jain >Priority: Blocker > Fix For: 1.9.0, 1.10, 1.8.2 > > Attachments: OAK-7223-2.patch, OAK-7223-3.patch, OAK-7223.patch > > > The FileCache#load method needs to clean the files which may have been > downloaded partially in case of errors from backend. This partially > downloaded file should be removed before returning from the method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-5051) Document XPath (and SQL-2) syntax as supported by Oak
[
https://issues.apache.org/jira/browse/OAK-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16349076#comment-16349076
]
Vikas Saurabh commented on OAK-5051:
[~tmueller], can you check out {{OAK-5051-grammar-railroads}} \[0] branch at my
fork. I've updated {{grammar-xpath.md}} \[1] to utilize a doxia macro (part of
the same branch) that renders railroads using very similar logic that you were
using at h2 railroad documentation.
\[0]:
https://github.com/catholicon/jackrabbit-oak/tree/OAK-5051-grammar-railroads
\[1]:
https://raw.githubusercontent.com/catholicon/jackrabbit-oak/OAK-5051-grammar-railroads/oak-doc/src/site/markdown/query/grammar-xpath.md
> Document XPath (and SQL-2) syntax as supported by Oak
> -
>
> Key: OAK-5051
> URL: https://issues.apache.org/jira/browse/OAK-5051
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> The JCR 2.0 SQL-2 language is documented at
> http://h2database.com/jcr/grammar.html
> But extensions to that are not documented. And XPath (as supported by Oak) is
> not documented at all.
> It would be good to have such a documentation, with examples.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7232) MountPermissionProvider.load can return null
[
https://issues.apache.org/jira/browse/OAK-7232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16349034#comment-16349034
]
angela commented on OAK-7232:
-
[~stillalex], thanks... i will try to additionally write some more test for
{{MountPermissionStore}} before pushing the change.
> MountPermissionProvider.load can return null
>
>
> Key: OAK-7232
> URL: https://issues.apache.org/jira/browse/OAK-7232
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Attachments: OAK-7232.patch
>
>
> while adding missing annotations to {{MountPermissionProvider}} i noticed
> that the load method is actually defined as follows on the interface:
> {code}
> /**
> * Loads the permission entries for the given principal and path. if the
> given {@code entries} is {@code null}, it
> * will be created automatically if needed. If a {@code entries} is
> given, it will reuse it and the same object is
> * returned. If no entries can be found for the given principal or path,
> {@code null} is returned.
> *
> * @param entries the permission entries or {@code null}
> * @param principalName name of the principal
> * @param path access controlled path.
> * @return the given {@code entries}, a new collection or {@code null}
> */
> @CheckForNull
> Collection load(@Nullable Collection
> entries, @Nonnull String principalName, @Nonnull String path);
> {code}
> IMO this means that the implementation in {{MountPermissionProvider}} could
> return {{null}} instead of creating an empty set.
> [~stillalex], wdyt? (proposed patch including the missing annoatations
> attached).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7233) Improve rep:glob documentation
[
https://issues.apache.org/jira/browse/OAK-7233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-7233:
-
Description:
The examples at
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Examples
do not explicitly mention the root node. For the root node you must never use
a {{rep:glob}} starting with {{/}}.
Also the following points should be clarified:
* rep:glob affects both (child)node as well as property access
* a link towards
https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
would be helpful
* make clearer how a rep:glob ending with {{/}} is different from one not
ending with {{/}}
Also the description for
{{/cat/}} and {{cat/}} seem wrong because IMHO descendants are only considered
if the glob uses a {{*}}.
This was originally triggered via
https://issues.apache.org/jira/browse/OAK-7233.
was:
The examples at
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Examples
do not explicitly mention the root node. For the root node you must never use
a {{rep:glob}} starting with {{/}}.
Also the following points should be clarified:
* rep:glob affects both (child)node as well as property access
* a link towards
https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
would be helpful
* make clearer how a rep:glob ending with {{/}} is different from one not
ending with {{/}}
This was originally triggered via
https://issues.apache.org/jira/browse/OAK-7233.
> Improve rep:glob documentation
> --
>
> Key: OAK-7233
> URL: https://issues.apache.org/jira/browse/OAK-7233
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: core, security
>Reporter: Konrad Windszus
>Assignee: angela
>Priority: Minor
> Fix For: 1.10
>
>
> The examples at
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Examples
> do not explicitly mention the root node. For the root node you must never
> use a {{rep:glob}} starting with {{/}}.
> Also the following points should be clarified:
> * rep:glob affects both (child)node as well as property access
> * a link towards
> https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
> would be helpful
> * make clearer how a rep:glob ending with {{/}} is different from one not
> ending with {{/}}
> Also the description for
> {{/cat/}} and {{cat/}} seem wrong because IMHO descendants are only
> considered if the glob uses a {{*}}.
> This was originally triggered via
> https://issues.apache.org/jira/browse/OAK-7233.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7233) Improve rep:glob documentation
[
https://issues.apache.org/jira/browse/OAK-7233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-7233:
Fix Version/s: 1.10
> Improve rep:glob documentation
> --
>
> Key: OAK-7233
> URL: https://issues.apache.org/jira/browse/OAK-7233
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: core, security
>Reporter: Konrad Windszus
>Assignee: angela
>Priority: Minor
> Fix For: 1.10
>
>
> The examples at
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Examples
> do not explicitly mention the root node. For the root node you must never
> use a {{rep:glob}} starting with {{/}}.
> Also the following points should be clarified:
> * rep:glob affects both (child)node as well as property access
> * a link towards
> https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
> would be helpful
> * make clearer how a rep:glob ending with {{/}} is different from one not
> ending with {{/}}
> This was originally triggered via
> https://issues.apache.org/jira/browse/OAK-7233.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7233) Improve rep:glob documentation
[
https://issues.apache.org/jira/browse/OAK-7233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-7233:
Component/s: security
core
> Improve rep:glob documentation
> --
>
> Key: OAK-7233
> URL: https://issues.apache.org/jira/browse/OAK-7233
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: core, security
>Reporter: Konrad Windszus
>Assignee: angela
>Priority: Minor
> Fix For: 1.10
>
>
> The examples at
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Examples
> do not explicitly mention the root node. For the root node you must never
> use a {{rep:glob}} starting with {{/}}.
> Also the following points should be clarified:
> * rep:glob affects both (child)node as well as property access
> * a link towards
> https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
> would be helpful
> * make clearer how a rep:glob ending with {{/}} is different from one not
> ending with {{/}}
> This was originally triggered via
> https://issues.apache.org/jira/browse/OAK-7233.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7233) Improve rep:glob documentation
[
https://issues.apache.org/jira/browse/OAK-7233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-7233:
Priority: Minor (was: Major)
> Improve rep:glob documentation
> --
>
> Key: OAK-7233
> URL: https://issues.apache.org/jira/browse/OAK-7233
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: core, security
>Reporter: Konrad Windszus
>Assignee: angela
>Priority: Minor
> Fix For: 1.10
>
>
> The examples at
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Examples
> do not explicitly mention the root node. For the root node you must never
> use a {{rep:glob}} starting with {{/}}.
> Also the following points should be clarified:
> * rep:glob affects both (child)node as well as property access
> * a link towards
> https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
> would be helpful
> * make clearer how a rep:glob ending with {{/}} is different from one not
> ending with {{/}}
> This was originally triggered via
> https://issues.apache.org/jira/browse/OAK-7233.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (OAK-7233) Improve rep:glob documentation
[
https://issues.apache.org/jira/browse/OAK-7233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela reassigned OAK-7233:
---
Assignee: angela
> Improve rep:glob documentation
> --
>
> Key: OAK-7233
> URL: https://issues.apache.org/jira/browse/OAK-7233
> Project: Jackrabbit Oak
> Issue Type: Documentation
>Reporter: Konrad Windszus
>Assignee: angela
>Priority: Major
>
> The examples at
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Examples
> do not explicitly mention the root node. For the root node you must never
> use a {{rep:glob}} starting with {{/}}.
> Also the following points should be clarified:
> * rep:glob affects both (child)node as well as property access
> * a link towards
> https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
> would be helpful
> * make clearer how a rep:glob ending with {{/}} is different from one not
> ending with {{/}}
> This was originally triggered via
> https://issues.apache.org/jira/browse/OAK-7233.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7233) Improve rep:glob documentation
[
https://issues.apache.org/jira/browse/OAK-7233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-7233:
-
Description:
The examples at
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Examples
do not explicitly mention the root node. For the root node you must never use
a {{rep:glob}} starting with {{/}}.
Also the following points should be clarified:
* rep:glob affects both (child)node as well as property access
* a link towards
https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
would be helpful
* make clearer how a rep:glob ending with {{/}} is different from one not
ending with {{/}}
This was originally triggered via
https://issues.apache.org/jira/browse/OAK-7233.
was:
The examples at
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Examples
do not explicitly mention the root node. For the root node you must never use
a `rep:glob` starting with `/`.
Also the following points should be clarified:
* rep:glob affects both (child)node as well as property access
* a link towards
https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
would be helpful
* make clearer how a rep:glob ending with {{/}} is different from one not
ending with {{/}}
This was originally triggered via
https://issues.apache.org/jira/browse/OAK-7233.
> Improve rep:glob documentation
> --
>
> Key: OAK-7233
> URL: https://issues.apache.org/jira/browse/OAK-7233
> Project: Jackrabbit Oak
> Issue Type: Documentation
>Reporter: Konrad Windszus
>Priority: Major
>
> The examples at
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Examples
> do not explicitly mention the root node. For the root node you must never
> use a {{rep:glob}} starting with {{/}}.
> Also the following points should be clarified:
> * rep:glob affects both (child)node as well as property access
> * a link towards
> https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
> would be helpful
> * make clearer how a rep:glob ending with {{/}} is different from one not
> ending with {{/}}
> This was originally triggered via
> https://issues.apache.org/jira/browse/OAK-7233.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7233) Improve rep:glob documentation
[
https://issues.apache.org/jira/browse/OAK-7233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-7233:
-
Description:
The examples at
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Examples
do not explicitly mention the root node. For the root node you must never use
a `rep:glob` starting with `/`.
Also the following points should be clarified:
* rep:glob affects both (child)node as well as property access
* a link towards
https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
would be helpful
* make clearer how a rep:glob ending with {{/}} is different from one not
ending with {{/}}
This was originally triggered via
https://issues.apache.org/jira/browse/OAK-7233.
was:
The examples at
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Examples
do not explicitly mention the root node. For the root node you must never use
a `rep:glob` starting with `/`.
Also the following points should be clarified:
* rep:glob affects both (child)node as well as property access
* a link towards
https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
would be helpful
* make clearer how a rep:glob ending with {{/}} is different from one not
ending with {{/}}
> Improve rep:glob documentation
> --
>
> Key: OAK-7233
> URL: https://issues.apache.org/jira/browse/OAK-7233
> Project: Jackrabbit Oak
> Issue Type: Documentation
>Reporter: Konrad Windszus
>Priority: Major
>
> The examples at
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Examples
> do not explicitly mention the root node. For the root node you must never
> use a `rep:glob` starting with `/`.
> Also the following points should be clarified:
> * rep:glob affects both (child)node as well as property access
> * a link towards
> https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
> would be helpful
> * make clearer how a rep:glob ending with {{/}} is different from one not
> ending with {{/}}
> This was originally triggered via
> https://issues.apache.org/jira/browse/OAK-7233.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-7233) Improve rep:glob documentation
Konrad Windszus created OAK-7233:
Summary: Improve rep:glob documentation
Key: OAK-7233
URL: https://issues.apache.org/jira/browse/OAK-7233
Project: Jackrabbit Oak
Issue Type: Documentation
Reporter: Konrad Windszus
The examples at
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Examples
do not explicitly mention the root node. For the root node you must never use
a `rep:glob` starting with `/`.
Also the following points should be clarified:
* rep:glob affects both (child)node as well as property access
* a link towards
https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
would be helpful
* make clearer how a rep:glob ending with {{/}} is different from one not
ending with {{/}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7229) Build Jackrabbit Oak #1218 failed
[
https://issues.apache.org/jira/browse/OAK-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348885#comment-16348885
]
Hudson commented on OAK-7229:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#1221|https://builds.apache.org/job/Jackrabbit%20Oak/1221/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1221/console]
> Build Jackrabbit Oak #1218 failed
> -
>
> Key: OAK-7229
> URL: https://issues.apache.org/jira/browse/OAK-7229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1218 has failed.
> First failed run: [Jackrabbit Oak
> #1218|https://builds.apache.org/job/Jackrabbit%20Oak/1218/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1218/console]
> SVN update failed with:
> {noformat}
> Updating https://svn.apache.org/repos/asf/jackrabbit/oak/trunk at revision
> '2018-02-01T07:45:23.929 +'
> ERROR: Failed to update https://svn.apache.org/repos/asf/jackrabbit/oak/trunk
> org.tmatesoft.svn.core.SVNException: svn: E200030: FULL
> at
> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:70)
> at
> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57)
> at
> org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.createSqlJetError(SVNSqlJetDb.java:195)
> at
> org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.beginTransaction(SVNSqlJetDb.java:211)
> at
> org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:257)
> at
> org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:252)
> at
> org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.obtainWCLock(SVNWCDb.java:5867)
> at
> org.tmatesoft.svn.core.internal.wc17.SVNWCContext.acquireWriteLock(SVNWCContext.java:1646)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:106)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:40)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
> at
> org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-5506) reject item names with unpaired surrogates early
[
https://issues.apache.org/jira/browse/OAK-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348865#comment-16348865
]
Julian Reschke commented on OAK-5506:
-
Tests rerun with {{-DStringWriteTest.propertyCount=1000}}.
Old:
{noformat}
Apache Jackrabbit Oak 1.10-SNAPSHOT
# StringWriteTest C min 10% 50% 90% max
N
Oak-Segment-Tar1 15 15 31 32 79
2171
Oak-Segment-Tar1 11 15 31 32 78
2088
Oak-Segment-Tar1 12 15 31 32 69
2153
Oak-Segment-Tar1 10 15 31 32 79
2024
{noformat}
New:
{noformat}
Apache Jackrabbit Oak 1.10-SNAPSHOT
# StringWriteTest C min 10% 50% 90% max
N
Oak-Segment-Tar1 9 15 31 32 78
2073
Oak-Segment-Tar1 15 15 31 32 63
2113
Oak-Segment-Tar1 13 15 31 32 78
2070
Oak-Segment-Tar1 13 15 31 35 79
2026
{noformat}
> reject item names with unpaired surrogates early
>
>
> Key: OAK-5506
> URL: https://issues.apache.org/jira/browse/OAK-5506
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: core, jcr, segment-tar
>Affects Versions: 1.5.18
>Reporter: Julian Reschke
>Priority: Minor
> Fix For: 1.10
>
> Attachments: OAK-5506-01.patch, OAK-5506-02.patch, OAK-5506-4.diff,
> OAK-5506-bench.diff, OAK-5506-name-conversion.diff, OAK-5506-segment.diff,
> OAK-5506-segment2.diff, OAK-5506.diff, ValidNamesTest.java
>
>
> Apparently, the following node name is accepted:
>{{"foo\ud800"}}
> but a subsequent {{getPath()}} call fails:
> {noformat}
> javax.jcr.InvalidItemStateException: This item [/test_node/foo?] does not
> exist anymore
> at
> org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:86)
> at
> org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:615)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:205)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getPath(ItemImpl.java:140)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getPath(NodeImpl.java:106)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.nameTest(ValidNamesTest.java:271)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.testUnpairedSurrogate(ValidNamesTest.java:259)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source){noformat}
> (test case follows)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-4318) Upgrade oak-solr to Solr 5.x
[ https://issues.apache.org/jira/browse/OAK-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated OAK-4318: - Fix Version/s: 1.6.9 > Upgrade oak-solr to Solr 5.x > > > Key: OAK-4318 > URL: https://issues.apache.org/jira/browse/OAK-4318 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.7.14, 1.8.0, 1.6.9 > > Attachments: OAK-4318.1.patch, OAK-4318.patch > > > Since we support JDK 1.7+ we can upgrade Solr to 5.x versions (not 6.0 as it > requires java 8 though). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-7231) Remove PermissionEntryCache.getNumEntries
[
https://issues.apache.org/jira/browse/OAK-7231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-7231.
-
Resolution: Fixed
Fix Version/s: 1.9.0
Committed revision 1822881.
> Remove PermissionEntryCache.getNumEntries
> -
>
> Key: OAK-7231
> URL: https://issues.apache.org/jira/browse/OAK-7231
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.9.0
>
> Attachments: OAK-7231.patch
>
>
> [~stillalex], i looks to me that {{PermissionEntryCache.getNumEntries}} is
> redundant and the single place where it is called could be replaced by
> {{PermissionStore.getNumEntries}}.
> here is why: the method is only call upon
> {{PermissionEntryProviderImpl.init}}, which itself is only called if the
> cache is still empty or if it just has been flushed.
> while i don't see an immediate drawback of the method itself, it would IMO
> improve readability and clarity.
> but i definitely want to wait for your review and ok in order to make sure, i
> don't miss something fundamental in such a key area of the permission
> evaluation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7229) Build Jackrabbit Oak #1218 failed
[
https://issues.apache.org/jira/browse/OAK-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348670#comment-16348670
]
Hudson commented on OAK-7229:
-
Build is still failing.
Failed run: [Jackrabbit Oak
#1220|https://builds.apache.org/job/Jackrabbit%20Oak/1220/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1220/console]
> Build Jackrabbit Oak #1218 failed
> -
>
> Key: OAK-7229
> URL: https://issues.apache.org/jira/browse/OAK-7229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1218 has failed.
> First failed run: [Jackrabbit Oak
> #1218|https://builds.apache.org/job/Jackrabbit%20Oak/1218/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1218/console]
> SVN update failed with:
> {noformat}
> Updating https://svn.apache.org/repos/asf/jackrabbit/oak/trunk at revision
> '2018-02-01T07:45:23.929 +'
> ERROR: Failed to update https://svn.apache.org/repos/asf/jackrabbit/oak/trunk
> org.tmatesoft.svn.core.SVNException: svn: E200030: FULL
> at
> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:70)
> at
> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57)
> at
> org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.createSqlJetError(SVNSqlJetDb.java:195)
> at
> org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.beginTransaction(SVNSqlJetDb.java:211)
> at
> org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:257)
> at
> org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:252)
> at
> org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.obtainWCLock(SVNWCDb.java:5867)
> at
> org.tmatesoft.svn.core.internal.wc17.SVNWCContext.acquireWriteLock(SVNWCContext.java:1646)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:106)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:40)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
> at
> org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7232) MountPermissionProvider.load can return null
[
https://issues.apache.org/jira/browse/OAK-7232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348655#comment-16348655
]
Alex Deparvu commented on OAK-7232:
---
patch looks good. I don't like returning nulls, but I don't have a strong
preference, so feel free to apply the patch as is.
> MountPermissionProvider.load can return null
>
>
> Key: OAK-7232
> URL: https://issues.apache.org/jira/browse/OAK-7232
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Attachments: OAK-7232.patch
>
>
> while adding missing annotations to {{MountPermissionProvider}} i noticed
> that the load method is actually defined as follows on the interface:
> {code}
> /**
> * Loads the permission entries for the given principal and path. if the
> given {@code entries} is {@code null}, it
> * will be created automatically if needed. If a {@code entries} is
> given, it will reuse it and the same object is
> * returned. If no entries can be found for the given principal or path,
> {@code null} is returned.
> *
> * @param entries the permission entries or {@code null}
> * @param principalName name of the principal
> * @param path access controlled path.
> * @return the given {@code entries}, a new collection or {@code null}
> */
> @CheckForNull
> Collection load(@Nullable Collection
> entries, @Nonnull String principalName, @Nonnull String path);
> {code}
> IMO this means that the implementation in {{MountPermissionProvider}} could
> return {{null}} instead of creating an empty set.
> [~stillalex], wdyt? (proposed patch including the missing annoatations
> attached).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7231) Remove PermissionEntryCache.getNumEntries
[
https://issues.apache.org/jira/browse/OAK-7231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348649#comment-16348649
]
Alex Deparvu commented on OAK-7231:
---
looks good!
> Remove PermissionEntryCache.getNumEntries
> -
>
> Key: OAK-7231
> URL: https://issues.apache.org/jira/browse/OAK-7231
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Attachments: OAK-7231.patch
>
>
> [~stillalex], i looks to me that {{PermissionEntryCache.getNumEntries}} is
> redundant and the single place where it is called could be replaced by
> {{PermissionStore.getNumEntries}}.
> here is why: the method is only call upon
> {{PermissionEntryProviderImpl.init}}, which itself is only called if the
> cache is still empty or if it just has been flushed.
> while i don't see an immediate drawback of the method itself, it would IMO
> improve readability and clarity.
> but i definitely want to wait for your review and ok in order to make sure, i
> don't miss something fundamental in such a key area of the permission
> evaluation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7232) MountPermissionProvider.load can return null
[
https://issues.apache.org/jira/browse/OAK-7232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-7232:
Description:
while adding missing annotations to {{MountPermissionProvider}} i noticed that
the load method is actually defined as follows on the interface:
{code}
/**
* Loads the permission entries for the given principal and path. if the
given {@code entries} is {@code null}, it
* will be created automatically if needed. If a {@code entries} is given,
it will reuse it and the same object is
* returned. If no entries can be found for the given principal or path,
{@code null} is returned.
*
* @param entries the permission entries or {@code null}
* @param principalName name of the principal
* @param path access controlled path.
* @return the given {@code entries}, a new collection or {@code null}
*/
@CheckForNull
Collection load(@Nullable Collection
entries, @Nonnull String principalName, @Nonnull String path);
{code}
IMO this means that the implementation in {{MountPermissionProvider}} could
return {{null}} instead of creating an empty set.
[~stillalex], wdyt? (proposed patch including the missing annoatations
attached).
was:
while adding missing annotations to {{MountPermissionProvider}} i noticed that
the load method is actually defined as follows on the interface:
{code}
/**
* Loads the permission entries for the given principal and path. if the
given {@code entries} is {@code null}, it
* will be created automatically if needed. If a {@code entries} is given,
it will reuse it and the same object is
* returned. If no entries can be found for the given principal or path,
{@code null} is returned.
*
* @param entries the permission entries or {@code null}
* @param principalName name of the principal
* @param path access controlled path.
* @return the given {@code entries}, a new collection or {@code null}
*/
@CheckForNull
Collection load(@Nullable Collection
entries, @Nonnull String principalName, @Nonnull String path);
{code}
IMO this means that the implementation in {{MountPermissionProvider}} could
return {{null}} instead of creating an empty set.
[~stillalex], wdyt? (proposed patch attached).
> MountPermissionProvider.load can return null
>
>
> Key: OAK-7232
> URL: https://issues.apache.org/jira/browse/OAK-7232
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Attachments: OAK-7232.patch
>
>
> while adding missing annotations to {{MountPermissionProvider}} i noticed
> that the load method is actually defined as follows on the interface:
> {code}
> /**
> * Loads the permission entries for the given principal and path. if the
> given {@code entries} is {@code null}, it
> * will be created automatically if needed. If a {@code entries} is
> given, it will reuse it and the same object is
> * returned. If no entries can be found for the given principal or path,
> {@code null} is returned.
> *
> * @param entries the permission entries or {@code null}
> * @param principalName name of the principal
> * @param path access controlled path.
> * @return the given {@code entries}, a new collection or {@code null}
> */
> @CheckForNull
> Collection load(@Nullable Collection
> entries, @Nonnull String principalName, @Nonnull String path);
> {code}
> IMO this means that the implementation in {{MountPermissionProvider}} could
> return {{null}} instead of creating an empty set.
> [~stillalex], wdyt? (proposed patch including the missing annoatations
> attached).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7232) MountPermissionProvider.load can return null
[
https://issues.apache.org/jira/browse/OAK-7232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-7232:
Description:
while adding missing annotations to {{MountPermissionProvider}} i noticed that
the load method is actually defined as follows on the interface:
{code}
/**
* Loads the permission entries for the given principal and path. if the
given {@code entries} is {@code null}, it
* will be created automatically if needed. If a {@code entries} is given,
it will reuse it and the same object is
* returned. If no entries can be found for the given principal or path,
{@code null} is returned.
*
* @param entries the permission entries or {@code null}
* @param principalName name of the principal
* @param path access controlled path.
* @return the given {@code entries}, a new collection or {@code null}
*/
@CheckForNull
Collection load(@Nullable Collection
entries, @Nonnull String principalName, @Nonnull String path);
{code}
IMO this means that the implementation in {{MountPermissionProvider}} could
return {{null}} instead of creating an empty set.
[~stillalex], wdyt? (proposed patch attached).
was:
while adding missing annotations to {{MountPermissionProvider}} i noticed that
the load method is actually defined as follows on the interface:
{code}
/**
* Loads the permission entries for the given principal and path. if the
given {@code entries} is {@code null}, it
* will be created automatically if needed. If a {@code entries} is given,
it will reuse it and the same object is
* returned. If no entries can be found for the given principal or path,
{@code null} is returned.
*
* @param entries the permission entries or {@code null}
* @param principalName name of the principal
* @param path access controlled path.
* @return the given {@code entries}, a new collection or {@code null}
*/
@CheckForNull
Collection load(@Nullable Collection
entries, @Nonnull String principalName, @Nonnull String path);
{code}
IMO this means that the implementation in {{MountPermissionProvider}} could
return {{null}} instead of creating an empty set.
[~stillalex], wdyt?
> MountPermissionProvider.load can return null
>
>
> Key: OAK-7232
> URL: https://issues.apache.org/jira/browse/OAK-7232
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Attachments: OAK-7232.patch
>
>
> while adding missing annotations to {{MountPermissionProvider}} i noticed
> that the load method is actually defined as follows on the interface:
> {code}
> /**
> * Loads the permission entries for the given principal and path. if the
> given {@code entries} is {@code null}, it
> * will be created automatically if needed. If a {@code entries} is
> given, it will reuse it and the same object is
> * returned. If no entries can be found for the given principal or path,
> {@code null} is returned.
> *
> * @param entries the permission entries or {@code null}
> * @param principalName name of the principal
> * @param path access controlled path.
> * @return the given {@code entries}, a new collection or {@code null}
> */
> @CheckForNull
> Collection load(@Nullable Collection
> entries, @Nonnull String principalName, @Nonnull String path);
> {code}
> IMO this means that the implementation in {{MountPermissionProvider}} could
> return {{null}} instead of creating an empty set.
> [~stillalex], wdyt? (proposed patch attached).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7232) MountPermissionProvider.load can return null
[
https://issues.apache.org/jira/browse/OAK-7232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-7232:
Attachment: OAK-7232.patch
> MountPermissionProvider.load can return null
>
>
> Key: OAK-7232
> URL: https://issues.apache.org/jira/browse/OAK-7232
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Attachments: OAK-7232.patch
>
>
> while adding missing annotations to {{MountPermissionProvider}} i noticed
> that the load method is actually defined as follows on the interface:
> {code}
> /**
> * Loads the permission entries for the given principal and path. if the
> given {@code entries} is {@code null}, it
> * will be created automatically if needed. If a {@code entries} is
> given, it will reuse it and the same object is
> * returned. If no entries can be found for the given principal or path,
> {@code null} is returned.
> *
> * @param entries the permission entries or {@code null}
> * @param principalName name of the principal
> * @param path access controlled path.
> * @return the given {@code entries}, a new collection or {@code null}
> */
> @CheckForNull
> Collection load(@Nullable Collection
> entries, @Nonnull String principalName, @Nonnull String path);
> {code}
> IMO this means that the implementation in {{MountPermissionProvider}} could
> return {{null}} instead of creating an empty set.
> [~stillalex], wdyt?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-7232) MountPermissionProvider.load can return null
angela created OAK-7232:
---
Summary: MountPermissionProvider.load can return null
Key: OAK-7232
URL: https://issues.apache.org/jira/browse/OAK-7232
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core, security
Reporter: angela
Assignee: angela
Attachments: OAK-7232.patch
while adding missing annotations to {{MountPermissionProvider}} i noticed that
the load method is actually defined as follows on the interface:
{code}
/**
* Loads the permission entries for the given principal and path. if the
given {@code entries} is {@code null}, it
* will be created automatically if needed. If a {@code entries} is given,
it will reuse it and the same object is
* returned. If no entries can be found for the given principal or path,
{@code null} is returned.
*
* @param entries the permission entries or {@code null}
* @param principalName name of the principal
* @param path access controlled path.
* @return the given {@code entries}, a new collection or {@code null}
*/
@CheckForNull
Collection load(@Nullable Collection
entries, @Nonnull String principalName, @Nonnull String path);
{code}
IMO this means that the implementation in {{MountPermissionProvider}} could
return {{null}} instead of creating an empty set.
[~stillalex], wdyt?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (OAK-5506) reject item names with unpaired surrogates early
[
https://issues.apache.org/jira/browse/OAK-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari reassigned OAK-5506:
---
Assignee: (was: Francesco Mari)
> reject item names with unpaired surrogates early
>
>
> Key: OAK-5506
> URL: https://issues.apache.org/jira/browse/OAK-5506
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: core, jcr, segment-tar
>Affects Versions: 1.5.18
>Reporter: Julian Reschke
>Priority: Minor
> Fix For: 1.10
>
> Attachments: OAK-5506-01.patch, OAK-5506-02.patch, OAK-5506-4.diff,
> OAK-5506-bench.diff, OAK-5506-name-conversion.diff, OAK-5506-segment.diff,
> OAK-5506-segment2.diff, OAK-5506.diff, ValidNamesTest.java
>
>
> Apparently, the following node name is accepted:
>{{"foo\ud800"}}
> but a subsequent {{getPath()}} call fails:
> {noformat}
> javax.jcr.InvalidItemStateException: This item [/test_node/foo?] does not
> exist anymore
> at
> org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:86)
> at
> org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:615)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:205)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getPath(ItemImpl.java:140)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getPath(NodeImpl.java:106)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.nameTest(ValidNamesTest.java:271)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.testUnpairedSurrogate(ValidNamesTest.java:259)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source){noformat}
> (test case follows)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (OAK-6345) Allow TokenLoginModule framework to create token for other LoginModules if userid is not known in login()
[
https://issues.apache.org/jira/browse/OAK-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-6345.
-
Resolution: Not A Problem
> Allow TokenLoginModule framework to create token for other LoginModules if
> userid is not known in login()
> -
>
> Key: OAK-6345
> URL: https://issues.apache.org/jira/browse/OAK-6345
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Alexander Klimetschek
>Priority: Major
>
> If a custom LoginModule accepting custom credentials (or
> ExternalIdentityProvider) wants to switch the credentials (e.g. on the first
> request of a web app) to a token from the TokenModule (i.e. return this in
> the (Simple)Credentials after login() for use by a request handler) this is
> currently not possible when the user id is not known up front in the login()
> call, but only detected by the custom LoginModule, and passed around between
> login modules using {{javax.security.auth.login.name}}.
> This is a follow up from OAK-3899.
> 1. The main recommendation there was, instead of the the TokenLoginModule
> respecting the shared key {{javax.security.auth.login.name}} and a special
> handling of SimpleCredentials as in the patch, leave this to a custom
> TokenProvider.
> This would require to change the TokenProvider API to pass through the key
> (or all keys), something along the lines of:
> {code:java}
> TokenInfo createToken(@Nonnull Credentials credentials, String loginName)
> {code}
> Since it also requires an application that has been relying on the default
> TokenProviderImpl, to replicate that logic, it might be desirable to make it
> easy to reuse that code. E.g. by wrapping and calling the other token
> provider (maybe this is already possible today in some way).
> 2. Another approach might be to call {{TokenInfo.createToken(userId,
> attributes)}} from the custom LoginModule aka ExternalIdentityProvider. The
> question then would be how it can access it (as e.g. osgi service) and if
> that's a good solution.
> 3. There might be another intended way through reusing the new
> CredentialsSupport from OAK-4129, but it seems the crucial
> {{javax.security.auth.login.name}} is not passed through to the relevant code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-6345) Allow TokenLoginModule framework to create token for other LoginModules if userid is not known in login()
[
https://issues.apache.org/jira/browse/OAK-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348596#comment-16348596
]
angela commented on OAK-6345:
-
[~alexander.klimetschek], i think that {{CredentialsSupport}} is exactly what
you are looking for. see also OAK-6662 for the latest improvements in that area.
> Allow TokenLoginModule framework to create token for other LoginModules if
> userid is not known in login()
> -
>
> Key: OAK-6345
> URL: https://issues.apache.org/jira/browse/OAK-6345
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Alexander Klimetschek
>Priority: Major
>
> If a custom LoginModule accepting custom credentials (or
> ExternalIdentityProvider) wants to switch the credentials (e.g. on the first
> request of a web app) to a token from the TokenModule (i.e. return this in
> the (Simple)Credentials after login() for use by a request handler) this is
> currently not possible when the user id is not known up front in the login()
> call, but only detected by the custom LoginModule, and passed around between
> login modules using {{javax.security.auth.login.name}}.
> This is a follow up from OAK-3899.
> 1. The main recommendation there was, instead of the the TokenLoginModule
> respecting the shared key {{javax.security.auth.login.name}} and a special
> handling of SimpleCredentials as in the patch, leave this to a custom
> TokenProvider.
> This would require to change the TokenProvider API to pass through the key
> (or all keys), something along the lines of:
> {code:java}
> TokenInfo createToken(@Nonnull Credentials credentials, String loginName)
> {code}
> Since it also requires an application that has been relying on the default
> TokenProviderImpl, to replicate that logic, it might be desirable to make it
> easy to reuse that code. E.g. by wrapping and calling the other token
> provider (maybe this is already possible today in some way).
> 2. Another approach might be to call {{TokenInfo.createToken(userId,
> attributes)}} from the custom LoginModule aka ExternalIdentityProvider. The
> question then would be how it can access it (as e.g. osgi service) and if
> that's a good solution.
> 3. There might be another intended way through reusing the new
> CredentialsSupport from OAK-4129, but it seems the crucial
> {{javax.security.auth.login.name}} is not passed through to the relevant code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-5506) reject item names with unpaired surrogates early
[
https://issues.apache.org/jira/browse/OAK-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348577#comment-16348577
]
Julian Reschke commented on OAK-5506:
-
bq. But I think we need to come up with a test case writing the old way and
reading the new way. This should be doable if there is a way to disable the new
behaviour I guess.
[~mduerig] - do you have something specific in mind? I could imagine a system
prop, but if we want to make it static we'd have to do major hacking in the
test case...
> reject item names with unpaired surrogates early
>
>
> Key: OAK-5506
> URL: https://issues.apache.org/jira/browse/OAK-5506
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: core, jcr, segment-tar
>Affects Versions: 1.5.18
>Reporter: Julian Reschke
>Assignee: Francesco Mari
>Priority: Minor
> Fix For: 1.10
>
> Attachments: OAK-5506-01.patch, OAK-5506-02.patch, OAK-5506-4.diff,
> OAK-5506-bench.diff, OAK-5506-name-conversion.diff, OAK-5506-segment.diff,
> OAK-5506-segment2.diff, OAK-5506.diff, ValidNamesTest.java
>
>
> Apparently, the following node name is accepted:
>{{"foo\ud800"}}
> but a subsequent {{getPath()}} call fails:
> {noformat}
> javax.jcr.InvalidItemStateException: This item [/test_node/foo?] does not
> exist anymore
> at
> org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:86)
> at
> org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:615)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:205)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getPath(ItemImpl.java:140)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getPath(NodeImpl.java:106)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.nameTest(ValidNamesTest.java:271)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.testUnpairedSurrogate(ValidNamesTest.java:259)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source){noformat}
> (test case follows)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-5506) reject item names with unpaired surrogates early
[
https://issues.apache.org/jira/browse/OAK-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348565#comment-16348565
]
Julian Reschke commented on OAK-5506:
-
trunk: [r1822875|http://svn.apache.org/r1822875] - documents that system
behavior for broken strings as "undefined" for now
> reject item names with unpaired surrogates early
>
>
> Key: OAK-5506
> URL: https://issues.apache.org/jira/browse/OAK-5506
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: core, jcr, segment-tar
>Affects Versions: 1.5.18
>Reporter: Julian Reschke
>Assignee: Francesco Mari
>Priority: Minor
> Fix For: 1.10
>
> Attachments: OAK-5506-01.patch, OAK-5506-02.patch, OAK-5506-4.diff,
> OAK-5506-bench.diff, OAK-5506-name-conversion.diff, OAK-5506-segment.diff,
> OAK-5506-segment2.diff, OAK-5506.diff, ValidNamesTest.java
>
>
> Apparently, the following node name is accepted:
>{{"foo\ud800"}}
> but a subsequent {{getPath()}} call fails:
> {noformat}
> javax.jcr.InvalidItemStateException: This item [/test_node/foo?] does not
> exist anymore
> at
> org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:86)
> at
> org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:615)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:205)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getPath(ItemImpl.java:140)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getPath(NodeImpl.java:106)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.nameTest(ValidNamesTest.java:271)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.testUnpairedSurrogate(ValidNamesTest.java:259)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source){noformat}
> (test case follows)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7231) Remove PermissionEntryCache.getNumEntries
[
https://issues.apache.org/jira/browse/OAK-7231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-7231:
Attachment: OAK-7231.patch
> Remove PermissionEntryCache.getNumEntries
> -
>
> Key: OAK-7231
> URL: https://issues.apache.org/jira/browse/OAK-7231
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Attachments: OAK-7231.patch
>
>
> [~stillalex], i looks to me that {{PermissionEntryCache.getNumEntries}} is
> redundant and the single place where it is called could be replaced by
> {{PermissionStore.getNumEntries}}.
> here is why: the method is only call upon
> {{PermissionEntryProviderImpl.init}}, which itself is only called if the
> cache is still empty or if it just has been flushed.
> while i don't see an immediate drawback of the method itself, it would IMO
> improve readability and clarity.
> but i definitely want to wait for your review and ok in order to make sure, i
> don't miss something fundamental in such a key area of the permission
> evaluation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-7231) Remove PermissionEntryCache.getNumEntries
angela created OAK-7231:
---
Summary: Remove PermissionEntryCache.getNumEntries
Key: OAK-7231
URL: https://issues.apache.org/jira/browse/OAK-7231
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core, security
Reporter: angela
Assignee: angela
[~stillalex], i looks to me that {{PermissionEntryCache.getNumEntries}} is
redundant and the single place where it is called could be replaced by
{{PermissionStore.getNumEntries}}.
here is why: the method is only call upon {{PermissionEntryProviderImpl.init}},
which itself is only called if the cache is still empty or if it just has been
flushed.
while i don't see an immediate drawback of the method itself, it would IMO
improve readability and clarity.
but i definitely want to wait for your review and ok in order to make sure, i
don't miss something fundamental in such a key area of the permission
evaluation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7230) Reduce calls to DocumentStore
[ https://issues.apache.org/jira/browse/OAK-7230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-7230: -- Labels: performance (was: ) > Reduce calls to DocumentStore > - > > Key: OAK-7230 > URL: https://issues.apache.org/jira/browse/OAK-7230 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > Labels: performance > Fix For: 1.10 > > > Analyze and further reduce calls to the DocumentStore when content is written > to the repository. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7230) Reduce calls to DocumentStore
Marcel Reutegger created OAK-7230: - Summary: Reduce calls to DocumentStore Key: OAK-7230 URL: https://issues.apache.org/jira/browse/OAK-7230 Project: Jackrabbit Oak Issue Type: Improvement Components: documentmk Reporter: Marcel Reutegger Assignee: Marcel Reutegger Fix For: 1.10 Analyze and further reduce calls to the DocumentStore when content is written to the repository. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7229) Build Jackrabbit Oak #1218 failed
[
https://issues.apache.org/jira/browse/OAK-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348363#comment-16348363
]
Hudson commented on OAK-7229:
-
Build is still failing.
Failed run: [Jackrabbit Oak
#1219|https://builds.apache.org/job/Jackrabbit%20Oak/1219/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1219/console]
> Build Jackrabbit Oak #1218 failed
> -
>
> Key: OAK-7229
> URL: https://issues.apache.org/jira/browse/OAK-7229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1218 has failed.
> First failed run: [Jackrabbit Oak
> #1218|https://builds.apache.org/job/Jackrabbit%20Oak/1218/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1218/console]
> SVN update failed with:
> {noformat}
> Updating https://svn.apache.org/repos/asf/jackrabbit/oak/trunk at revision
> '2018-02-01T07:45:23.929 +'
> ERROR: Failed to update https://svn.apache.org/repos/asf/jackrabbit/oak/trunk
> org.tmatesoft.svn.core.SVNException: svn: E200030: FULL
> at
> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:70)
> at
> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57)
> at
> org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.createSqlJetError(SVNSqlJetDb.java:195)
> at
> org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.beginTransaction(SVNSqlJetDb.java:211)
> at
> org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:257)
> at
> org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:252)
> at
> org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.obtainWCLock(SVNWCDb.java:5867)
> at
> org.tmatesoft.svn.core.internal.wc17.SVNWCContext.acquireWriteLock(SVNWCContext.java:1646)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:106)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:40)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
> at
> org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7229) Build Jackrabbit Oak #1218 failed
[
https://issues.apache.org/jira/browse/OAK-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-7229:
--
Description:
No description is provided
The build Jackrabbit Oak #1218 has failed.
First failed run: [Jackrabbit Oak
#1218|https://builds.apache.org/job/Jackrabbit%20Oak/1218/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1218/console]
SVN update failed with:
{noformat}
Updating https://svn.apache.org/repos/asf/jackrabbit/oak/trunk at revision
'2018-02-01T07:45:23.929 +'
ERROR: Failed to update https://svn.apache.org/repos/asf/jackrabbit/oak/trunk
org.tmatesoft.svn.core.SVNException: svn: E200030: FULL
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:70)
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57)
at
org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.createSqlJetError(SVNSqlJetDb.java:195)
at
org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.beginTransaction(SVNSqlJetDb.java:211)
at
org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:257)
at
org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:252)
at
org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.obtainWCLock(SVNWCDb.java:5867)
at
org.tmatesoft.svn.core.internal.wc17.SVNWCContext.acquireWriteLock(SVNWCContext.java:1646)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:106)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:40)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
{noformat}
was:
No description is provided
The build Jackrabbit Oak #1218 has failed.
First failed run: [Jackrabbit Oak
#1218|https://builds.apache.org/job/Jackrabbit%20Oak/1218/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/1218/console]
> Build Jackrabbit Oak #1218 failed
> -
>
> Key: OAK-7229
> URL: https://issues.apache.org/jira/browse/OAK-7229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #1218 has failed.
> First failed run: [Jackrabbit Oak
> #1218|https://builds.apache.org/job/Jackrabbit%20Oak/1218/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1218/console]
> SVN update failed with:
> {noformat}
> Updating https://svn.apache.org/repos/asf/jackrabbit/oak/trunk at revision
> '2018-02-01T07:45:23.929 +'
> ERROR: Failed to update https://svn.apache.org/repos/asf/jackrabbit/oak/trunk
> org.tmatesoft.svn.core.SVNException: svn: E200030: FULL
> at
> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:70)
> at
> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57)
> at
> org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.createSqlJetError(SVNSqlJetDb.java:195)
> at
> org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.beginTransaction(SVNSqlJetDb.java:211)
> at
> org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:257)
> at
> org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:252)
> at
> org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.obtainWCLock(SVNWCDb.java:5867)
> at
> org.tmatesoft.svn.core.internal.wc17.SVNWCContext.acquireWriteLock(SVNWCContext.java:1646)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:106)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:40)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18)
> at
> org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
> at
> org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
