[jira] [Resolved] (OAK-10655) Improve warning emitted for Unexpected changes performed on a non-default mount
[
https://issues.apache.org/jira/browse/OAK-10655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved OAK-10655.
---
Fix Version/s: 1.62.0
Resolution: Fixed
Fixed in
https://github.com/apache/jackrabbit-oak/commit/ba989d762e8bdd242cd5d25d20390361f8a18365.
> Improve warning emitted for Unexpected changes performed on a non-default
> mount
> ---
>
> Key: OAK-10655
> URL: https://issues.apache.org/jira/browse/OAK-10655
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: composite
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 1.62.0
>
>
> Currently the feature provided in OAK-9208 emits WARNs like the following
> {code}
> 5.02.2024 11:46:49.748 *WARN* [ResourceResolverFactory registration]
> org.apache.jackrabbit.oak.composite.impl.NonDefaultMountWriteReportingObserver$ChangeReporter
> Unexpected changes (38) performed on a non-default mount. Printing at most
> 50_- /apps : Changed_-
> java.lang.RuntimeException: null
> at
> org.apache.jackrabbit.oak.composite.impl.NonDefaultMountWriteReportingObserver$CountingDiff.report(NonDefaultMountWriteReportingObserver.java:106)
> at
> org.apache.jackrabbit.oak.composite.impl.NonDefaultMountWriteReportingObserver.contentChanged(NonDefaultMountWriteReportingObserver.java:88)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeObserver.contentChanged(CompositeObserver.java:51)
> at
> org.apache.jackrabbit.oak.spi.commit.ChangeDispatcher.contentChanged(ChangeDispatcher.java:79)
> at
> org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler$ObservableLockBasedScheduler.contentChanged(LockBasedScheduler.java:394)
> at
> org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler.execute(LockBasedScheduler.java:303)
> at
> org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler.schedule(LockBasedScheduler.java:270)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeStore.merge(SegmentNodeStore.java:211)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:262)
> at
> org.apache.jackrabbit.oak.jcr.delegate.WorkspaceDelegate$WorkspaceCopy.perform(WorkspaceDelegate.java:130)
> at
> org.apache.jackrabbit.oak.jcr.delegate.WorkspaceDelegate.copy(WorkspaceDelegate.java:99)
> at
> org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl$2.performVoid(WorkspaceImpl.java:163)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:299)
> at
> org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl.copy(WorkspaceImpl.java:150)
> at
> org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl.copy(WorkspaceImpl.java:132)
> at
> .
> {code}
> It would be useful to add a dedicated exception message to the throwable (or
> prevent logging it) and indicate that this only indicates where the JCR
> session has been committed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10655) Improve warning emitted for Unexpected changes performed on a non-default mount
[
https://issues.apache.org/jira/browse/OAK-10655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned OAK-10655:
-
Assignee: Konrad Windszus
> Improve warning emitted for Unexpected changes performed on a non-default
> mount
> ---
>
> Key: OAK-10655
> URL: https://issues.apache.org/jira/browse/OAK-10655
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the feature provided in OAK-9208 emits WARNs like the following
> {code}
> 5.02.2024 11:46:49.748 *WARN* [ResourceResolverFactory registration]
> org.apache.jackrabbit.oak.composite.impl.NonDefaultMountWriteReportingObserver$ChangeReporter
> Unexpected changes (38) performed on a non-default mount. Printing at most
> 50_- /apps : Changed_-
> java.lang.RuntimeException: null
> at
> org.apache.jackrabbit.oak.composite.impl.NonDefaultMountWriteReportingObserver$CountingDiff.report(NonDefaultMountWriteReportingObserver.java:106)
> at
> org.apache.jackrabbit.oak.composite.impl.NonDefaultMountWriteReportingObserver.contentChanged(NonDefaultMountWriteReportingObserver.java:88)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeObserver.contentChanged(CompositeObserver.java:51)
> at
> org.apache.jackrabbit.oak.spi.commit.ChangeDispatcher.contentChanged(ChangeDispatcher.java:79)
> at
> org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler$ObservableLockBasedScheduler.contentChanged(LockBasedScheduler.java:394)
> at
> org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler.execute(LockBasedScheduler.java:303)
> at
> org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler.schedule(LockBasedScheduler.java:270)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeStore.merge(SegmentNodeStore.java:211)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:262)
> at
> org.apache.jackrabbit.oak.jcr.delegate.WorkspaceDelegate$WorkspaceCopy.perform(WorkspaceDelegate.java:130)
> at
> org.apache.jackrabbit.oak.jcr.delegate.WorkspaceDelegate.copy(WorkspaceDelegate.java:99)
> at
> org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl$2.performVoid(WorkspaceImpl.java:163)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:299)
> at
> org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl.copy(WorkspaceImpl.java:150)
> at
> org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl.copy(WorkspaceImpl.java:132)
> at
> .
> {code}
> It would be useful to add a dedicated exception message to the throwable (or
> prevent logging it) and indicate that this only indicates where the JCR
> session has been committed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10655) Improve warning emitted for Unexpected changes performed on a non-default mount
[
https://issues.apache.org/jira/browse/OAK-10655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-10655:
--
Description:
Currently the feature provided in OAK-9208 emits WARNs like the following
{code}
5.02.2024 11:46:49.748 *WARN* [ResourceResolverFactory registration]
org.apache.jackrabbit.oak.composite.impl.NonDefaultMountWriteReportingObserver$ChangeReporter
Unexpected changes (38) performed on a non-default mount. Printing at most
50_- /apps : Changed_-
java.lang.RuntimeException: null
at
org.apache.jackrabbit.oak.composite.impl.NonDefaultMountWriteReportingObserver$CountingDiff.report(NonDefaultMountWriteReportingObserver.java:106)
at
org.apache.jackrabbit.oak.composite.impl.NonDefaultMountWriteReportingObserver.contentChanged(NonDefaultMountWriteReportingObserver.java:88)
at
org.apache.jackrabbit.oak.spi.commit.CompositeObserver.contentChanged(CompositeObserver.java:51)
at
org.apache.jackrabbit.oak.spi.commit.ChangeDispatcher.contentChanged(ChangeDispatcher.java:79)
at
org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler$ObservableLockBasedScheduler.contentChanged(LockBasedScheduler.java:394)
at
org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler.execute(LockBasedScheduler.java:303)
at
org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler.schedule(LockBasedScheduler.java:270)
at
org.apache.jackrabbit.oak.segment.SegmentNodeStore.merge(SegmentNodeStore.java:211)
at
org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:262)
at
org.apache.jackrabbit.oak.jcr.delegate.WorkspaceDelegate$WorkspaceCopy.perform(WorkspaceDelegate.java:130)
at
org.apache.jackrabbit.oak.jcr.delegate.WorkspaceDelegate.copy(WorkspaceDelegate.java:99)
at
org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl$2.performVoid(WorkspaceImpl.java:163)
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:299)
at
org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl.copy(WorkspaceImpl.java:150)
at
org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl.copy(WorkspaceImpl.java:132)
at
.
{code}
It would be useful to add a dedicated exception message to the throwable (or
prevent logging it) and indicate that this only indicates where the JCR session
has been committed.
was:
Currently the feature provided in OAK-9208 emits WARNs like the following
{code}
5.02.2024 11:46:49.748 *WARN* [ResourceResolverFactory registration]
org.apache.jackrabbit.oak.composite.impl.NonDefaultMountWriteReportingObserver$ChangeReporter
Unexpected changes (38) performed on a non-default mount. Printing at most
50_- /apps : Changed_-
java.lang.RuntimeException: null
at
org.apache.jackrabbit.oak.composite.impl.NonDefaultMountWriteReportingObserver$CountingDiff.report(NonDefaultMountWriteReportingObserver.java:106)
at
org.apache.jackrabbit.oak.composite.impl.NonDefaultMountWriteReportingObserver.contentChanged(NonDefaultMountWriteReportingObserver.java:88)
at
org.apache.jackrabbit.oak.spi.commit.CompositeObserver.contentChanged(CompositeObserver.java:51)
at
org.apache.jackrabbit.oak.spi.commit.ChangeDispatcher.contentChanged(ChangeDispatcher.java:79)
at
org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler$ObservableLockBasedScheduler.contentChanged(LockBasedScheduler.java:394)
at
org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler.execute(LockBasedScheduler.java:303)
at
org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler.schedule(LockBasedScheduler.java:270)
at
org.apache.jackrabbit.oak.segment.SegmentNodeStore.merge(SegmentNodeStore.java:211)
at
org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:262)
at
org.apache.jackrabbit.oak.jcr.delegate.WorkspaceDelegate$WorkspaceCopy.perform(WorkspaceDelegate.java:130)
at
org.apache.jackrabbit.oak.jcr.delegate.WorkspaceDelegate.copy(WorkspaceDelegate.java:99)
at
org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl$2.performVoid(WorkspaceImpl.java:163)
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:299)
at
org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl.copy(WorkspaceImpl.java:150)
at
org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl.copy(WorkspaceImpl.java:132)
at
biz.netcentric.cq.tools.actool.startuphook.impl.AcToolStartupHookServiceImpl.copyAcHistoryToOrFromApps(AcToolStartupHookServiceImpl.java:194)
at
biz.netcentric.cq.tools.actool.startuphook.impl.AcToolStartupHookServiceImpl.runAcTool(AcToolStartupHookServiceImpl.java:109)
at
[jira] [Created] (OAK-10655) Improve warning emitted for Unexpected changes performed on a non-default mount
Konrad Windszus created OAK-10655:
-
Summary: Improve warning emitted for Unexpected changes performed
on a non-default mount
Key: OAK-10655
URL: https://issues.apache.org/jira/browse/OAK-10655
Project: Jackrabbit Oak
Issue Type: Improvement
Reporter: Konrad Windszus
Currently the feature provided in OAK-9208 emits WARNs like the following
{code}
5.02.2024 11:46:49.748 *WARN* [ResourceResolverFactory registration]
org.apache.jackrabbit.oak.composite.impl.NonDefaultMountWriteReportingObserver$ChangeReporter
Unexpected changes (38) performed on a non-default mount. Printing at most
50_- /apps : Changed_-
java.lang.RuntimeException: null
at
org.apache.jackrabbit.oak.composite.impl.NonDefaultMountWriteReportingObserver$CountingDiff.report(NonDefaultMountWriteReportingObserver.java:106)
at
org.apache.jackrabbit.oak.composite.impl.NonDefaultMountWriteReportingObserver.contentChanged(NonDefaultMountWriteReportingObserver.java:88)
at
org.apache.jackrabbit.oak.spi.commit.CompositeObserver.contentChanged(CompositeObserver.java:51)
at
org.apache.jackrabbit.oak.spi.commit.ChangeDispatcher.contentChanged(ChangeDispatcher.java:79)
at
org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler$ObservableLockBasedScheduler.contentChanged(LockBasedScheduler.java:394)
at
org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler.execute(LockBasedScheduler.java:303)
at
org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler.schedule(LockBasedScheduler.java:270)
at
org.apache.jackrabbit.oak.segment.SegmentNodeStore.merge(SegmentNodeStore.java:211)
at
org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:262)
at
org.apache.jackrabbit.oak.jcr.delegate.WorkspaceDelegate$WorkspaceCopy.perform(WorkspaceDelegate.java:130)
at
org.apache.jackrabbit.oak.jcr.delegate.WorkspaceDelegate.copy(WorkspaceDelegate.java:99)
at
org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl$2.performVoid(WorkspaceImpl.java:163)
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:299)
at
org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl.copy(WorkspaceImpl.java:150)
at
org.apache.jackrabbit.oak.jcr.session.WorkspaceImpl.copy(WorkspaceImpl.java:132)
at
biz.netcentric.cq.tools.actool.startuphook.impl.AcToolStartupHookServiceImpl.copyAcHistoryToOrFromApps(AcToolStartupHookServiceImpl.java:194)
at
biz.netcentric.cq.tools.actool.startuphook.impl.AcToolStartupHookServiceImpl.runAcTool(AcToolStartupHookServiceImpl.java:109)
at
biz.netcentric.cq.tools.actool.startuphook.impl.AcToolStartupHookServiceImpl.activate(AcToolStartupHookServiceImpl.java:94)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:245)
at
org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41)
at
org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:687)
at
org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:531)
at
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:317)
at
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:307)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:354)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:115)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:1002)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:975)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:785)
at
org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:1274)
at
org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:1225)
at
org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1232)
at
org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1152)
at
[jira] [Resolved] (OAK-10601) Publish site directly from Git repo
[ https://issues.apache.org/jira/browse/OAK-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved OAK-10601. --- Resolution: Won't Fix This doesn't make sense: https://issues.apache.org/jira/browse/JCRSITE-55?focusedCommentId=17810346=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17810346 > Publish site directly from Git repo > --- > > Key: OAK-10601 > URL: https://issues.apache.org/jira/browse/OAK-10601 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: docs >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > As outlined in > https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto > the website should be directly published from the Git repository instead of > pushing to SVN first. This requires > - adjusting the > [maven-scm-publish-plugin|https://maven.apache.org/plugins/maven-scm-publish-plugin/] > to publish to a branch of the source repository > - adjusting the .asf.yaml -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10613) Set Java version in Jenkinsfile to 17 (for SonarCloud)
[ https://issues.apache.org/jira/browse/OAK-10613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808613#comment-17808613 ] Konrad Windszus commented on OAK-10613: --- IIUC correctly the Sonar check is executed by GitHub Actions, not by ASF Jenkins. Therefore one would need to tweak https://github.com/apache/jackrabbit-oak/blob/trunk/.github/workflows/build.yml. Going forward I would strongly recommend to maintain only one way of CI builds (probably GitHub Actions) and drop the other completely. > Set Java version in Jenkinsfile to 17 (for SonarCloud) > -- > > Key: OAK-10613 > URL: https://issues.apache.org/jira/browse/OAK-10613 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Julian Reschke >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10607) Rename Maven property "java.version"
[
https://issues.apache.org/jira/browse/OAK-10607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved OAK-10607.
---
Fix Version/s: 1.62.0
Resolution: Fixed
Fixed in
https://github.com/apache/jackrabbit-oak/commit/deeccbe0d4b8ff210d9adcf31fbe7c7f0d841dbc.
> Rename Maven property "java.version"
>
>
> Key: OAK-10607
> URL: https://issues.apache.org/jira/browse/OAK-10607
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: parent
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 1.62.0
>
>
> Maven exposes all Java System Properties as regular Maven properties.
> Currently the user property {{java.version}} hides the same named system
> property (
> https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-properties.html#resource-filtering-sect-system-properties),
> therefore it should be renamed to not hide the current JDK version exposed
> via the Java System Property.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10607) Rename Maven property "java.version"
[
https://issues.apache.org/jira/browse/OAK-10607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-10607:
--
Summary: Rename Maven property "java.version" (was: Rename Maven property
"java.version)
> Rename Maven property "java.version"
>
>
> Key: OAK-10607
> URL: https://issues.apache.org/jira/browse/OAK-10607
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: parent
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Maven exposes all Java System Properties as regular Maven properties.
> Currently the user property {{java.version}} hides the same named system
> property (
> https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-properties.html#resource-filtering-sect-system-properties),
> therefore it should be renamed to not hide the current JDK version exposed
> via the Java System Property.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10607) Rename Maven property "java.version
Konrad Windszus created OAK-10607:
-
Summary: Rename Maven property "java.version
Key: OAK-10607
URL: https://issues.apache.org/jira/browse/OAK-10607
Project: Jackrabbit Oak
Issue Type: Improvement
Components: parent
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Maven exposes all Java System Properties as regular Maven properties. Currently
the user property {{java.version}} hides the same named system property (
https://books.sonatype.com/mvnref-book/reference/resource-filtering-sect-properties.html#resource-filtering-sect-system-properties),
therefore it should be renamed to not hide the current JDK version exposed via
the Java System Property.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10602) Publish site directly from Git repo
Konrad Windszus created OAK-10602: - Summary: Publish site directly from Git repo Key: OAK-10602 URL: https://issues.apache.org/jira/browse/OAK-10602 Project: Jackrabbit Oak Issue Type: Improvement Components: docs Reporter: Konrad Windszus Assignee: Konrad Windszus As outlined in https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto the website should be directly published from the Git repository instead of pushing to SVN first. This requires - adjusting the [maven-scm-publish-plugin|https://maven.apache.org/plugins/maven-scm-publish-plugin/] to publish to a branch of the source repository - adjusting the .asf.yaml -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10601) Publish site directly from Git repo
Konrad Windszus created OAK-10601: - Summary: Publish site directly from Git repo Key: OAK-10601 URL: https://issues.apache.org/jira/browse/OAK-10601 Project: Jackrabbit Oak Issue Type: Improvement Components: docs Reporter: Konrad Windszus Assignee: Konrad Windszus As outlined in https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto the website should be directly published from the Git repository instead of pushing to SVN first. This requires - adjusting the [maven-scm-publish-plugin|https://maven.apache.org/plugins/maven-scm-publish-plugin/] to publish to a branch of the source repository - adjusting the .asf.yaml -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10523) Basic SNS support returns invalid node names
[
https://issues.apache.org/jira/browse/OAK-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781411#comment-17781411
]
Konrad Windszus commented on OAK-10523:
---
Right, Oak is SNS read only, but the exception should be thrown while trying to
create the SNS not when trying to read it.
> Basic SNS support returns invalid node names
>
>
> Key: OAK-10523
> URL: https://issues.apache.org/jira/browse/OAK-10523
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
>
> When encountering names using index notation in storage, oak-jcr treats the
> index suffix as part of the name. This causes issues with other components
> that assume that the result of {{Node.getName()}} is indeed a valid JCR name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10523) Basic SNS support returns invalid node names
[
https://issues.apache.org/jira/browse/OAK-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781411#comment-17781411
]
Konrad Windszus edited comment on OAK-10523 at 10/31/23 2:52 PM:
-
Right, Oak is SNS read only, but the exception should be thrown while trying to
create the SNS node not when trying to read it.
was (Author: kwin):
Right, Oak is SNS read only, but the exception should be thrown while trying to
create the SNS not when trying to read it.
> Basic SNS support returns invalid node names
>
>
> Key: OAK-10523
> URL: https://issues.apache.org/jira/browse/OAK-10523
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
>
> When encountering names using index notation in storage, oak-jcr treats the
> index suffix as part of the name. This causes issues with other components
> that assume that the result of {{Node.getName()}} is indeed a valid JCR name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10523) Basic SNS support returns invalid node names
[
https://issues.apache.org/jira/browse/OAK-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781402#comment-17781402
]
Konrad Windszus edited comment on OAK-10523 at 10/31/23 2:44 PM:
-
Instead of modifying the behaviour of Node.getName() one could also fix/relax
the handling of APIs called on top of Node.getName(). IIUC then this was faced
with
[{{NameResolver.getQName(String)}}|https://jackrabbit.apache.org/api/trunk/org/apache/jackrabbit/spi/commons/conversion/NameResolver.html#getQName-java.lang.String-]
although the javadoc currently explicitly states that it throws
{{IllegalNameException}} when an invalid JCR name is passed.
was (Author: kwin):
Instead of modifying the behaviour of Node.getName() one could also fix/relax
the handling of APIs called on top of Node.getName(). IIUC then this was faced
with
[{{NameResolver.getQName(String)}}|https://jackrabbit.apache.org/api/trunk/org/apache/jackrabbit/spi/commons/conversion/NameResolver.html#getQName-java.lang.String-]
> Basic SNS support returns invalid node names
>
>
> Key: OAK-10523
> URL: https://issues.apache.org/jira/browse/OAK-10523
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
>
> When encountering names using index notation in storage, oak-jcr treats the
> index suffix as part of the name. This causes issues with other components
> that assume that the result of {{Node.getName()}} is indeed a valid JCR name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10523) Basic SNS support returns invalid node names
[
https://issues.apache.org/jira/browse/OAK-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781402#comment-17781402
]
Konrad Windszus commented on OAK-10523:
---
Instead of modifying the behaviour of Node.getName() one could also fix/relax
the handling of APIs called on top of Node.getName(). IIUC then this was faced
with
[{{NameResolver.getQName(String)}}|https://jackrabbit.apache.org/api/trunk/org/apache/jackrabbit/spi/commons/conversion/NameResolver.html#getQName-java.lang.String-]
> Basic SNS support returns invalid node names
>
>
> Key: OAK-10523
> URL: https://issues.apache.org/jira/browse/OAK-10523
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
>
> When encountering names using index notation in storage, oak-jcr treats the
> index suffix as part of the name. This causes issues with other components
> that assume that the result of {{Node.getName()}} is indeed a valid JCR name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10500) javadoc:aggregate build fails again
[ https://issues.apache.org/jira/browse/OAK-10500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1184#comment-1184 ] Konrad Windszus edited comment on OAK-10500 at 10/19/23 10:57 AM: -- No need to modify the pom. One can use the approach outlined in https://stackoverflow.com/a/32980111/5155923 to exclude certain modules. Probably it would be good idea to add the command line used to generate the aggregate javadoc somewhere in the documentation. Alternatively we can configure the skipped modules for javadoc only via https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html#skippedModules. was (Author: kwin): No need to modify the pom. One can use the approach outlined in https://stackoverflow.com/a/32980111/5155923 to exclude certain modules. Probably it would be good idea to add the command line used to generate the aggregate javadoc somewhere in the documentation. Alternatively we can configure the skipped modules for javadoc via https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html#skippedModules. > javadoc:aggregate build fails again > --- > > Key: OAK-10500 > URL: https://issues.apache.org/jira/browse/OAK-10500 > Project: Jackrabbit Oak > Issue Type: Bug > Components: doc >Reporter: Julian Reschke >Priority: Minor > > For the public site, we're creating aggregate Javadocs for the whole project. > This fails since the switch to Java 11, and is caused by the project pulling > in different versions of lucene-core, which are not compatible (oak-update > uses a historic one from Jackrabbit, oak-solr one a newer one than the > defaulr project). > In addition, doc generation for the groovy classes fails when shaded Guava is > in the reactor. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OAK-10500) javadoc:aggregate build fails again
[ https://issues.apache.org/jira/browse/OAK-10500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1184#comment-1184 ] Konrad Windszus edited comment on OAK-10500 at 10/19/23 10:49 AM: -- No need to modify the pom. One can use the approach outlined in https://stackoverflow.com/a/32980111/5155923 to exclude certain modules. Probably it would be good idea to add the command line used to generate the aggregate javadoc somewhere in the documentation. Alternatively we can configure the skipped modules for javadoc via https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html#skippedModules. was (Author: kwin): No need to modify the pom. One can use the approach outlined in https://stackoverflow.com/a/32980111/5155923 to exclude certain modules. Probably it would be good idea to add the command line used to generate the aggregate javadoc somewhere in the documentation. > javadoc:aggregate build fails again > --- > > Key: OAK-10500 > URL: https://issues.apache.org/jira/browse/OAK-10500 > Project: Jackrabbit Oak > Issue Type: Bug > Components: doc >Reporter: Julian Reschke >Priority: Minor > > For the public site, we're creating aggregate Javadocs for the whole project. > This fails since the switch to Java 11, and is caused by the project pulling > in different versions of lucene-core, which are not compatible (oak-update > uses a historic one from Jackrabbit, oak-solr one a newer one than the > defaulr project). > In addition, doc generation for the groovy classes fails when shaded Guava is > in the reactor. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OAK-10500) javadoc:aggregate build fails again
[ https://issues.apache.org/jira/browse/OAK-10500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1184#comment-1184 ] Konrad Windszus edited comment on OAK-10500 at 10/19/23 10:49 AM: -- No need to modify the pom. One can use the approach outlined in https://stackoverflow.com/a/32980111/5155923 to exclude certain modules. Probably it would be good idea to add the command line used to generate the aggregate javadoc somewhere in the documentation. was (Author: kwin): No need to modify the pom. One can use the approach outlined in https://stackoverflow.com/a/32980111/5155923. Probably it would be good idea to add the command line used to generate the aggregate javadoc somewhere in the documentation. > javadoc:aggregate build fails again > --- > > Key: OAK-10500 > URL: https://issues.apache.org/jira/browse/OAK-10500 > Project: Jackrabbit Oak > Issue Type: Bug > Components: doc >Reporter: Julian Reschke >Priority: Minor > > For the public site, we're creating aggregate Javadocs for the whole project. > This fails since the switch to Java 11, and is caused by the project pulling > in different versions of lucene-core, which are not compatible (oak-update > uses a historic one from Jackrabbit, oak-solr one a newer one than the > defaulr project). > In addition, doc generation for the groovy classes fails when shaded Guava is > in the reactor. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10500) javadoc:aggregate build fails again
[ https://issues.apache.org/jira/browse/OAK-10500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1184#comment-1184 ] Konrad Windszus commented on OAK-10500: --- No need to modify the pom. One can use the approach outlined in https://stackoverflow.com/a/32980111/5155923. Probably it would be good idea to add the command line used to generate the aggregate javadoc somewhere in the documentation. > javadoc:aggregate build fails again > --- > > Key: OAK-10500 > URL: https://issues.apache.org/jira/browse/OAK-10500 > Project: Jackrabbit Oak > Issue Type: Bug > Components: doc >Reporter: Julian Reschke >Priority: Minor > > For the public site, we're creating aggregate Javadocs for the whole project. > This fails since the switch to Java 11, and is caused by the project pulling > in different versions of lucene-core, which are not compatible (oak-update > uses a historic one from Jackrabbit, oak-solr one a newer one than the > defaulr project). > In addition, doc generation for the groovy classes fails when shaded Guava is > in the reactor. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10448) org.apache.jackrabbit.api.security.user.Query must be a Consumer type
[
https://issues.apache.org/jira/browse/OAK-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved OAK-10448.
---
Resolution: Fixed
> org.apache.jackrabbit.api.security.user.Query must be a Consumer type
> -
>
> Key: OAK-10448
> URL: https://issues.apache.org/jira/browse/OAK-10448
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jackrabbit-api
>Affects Versions: 1.54.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 1.58.0
>
>
> In the context of OAK-10252 the interface
> {{org.apache.jackrabbit.api.security.user.Query}} was incorrectly converted
> from implicit consumer type to provider type
> (https://github.com/apache/jackrabbit-oak/blob/dcd46825e21f373fda8dbfe61cdaeac522fe15eb/oak-jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/user/Query.java#L45).
> In fact this interface is supposed to be implemented by consumers (e.g.
> those leveraging
> {{org.apache.jackrabbit.api.security.user.UserManager#findAuthorizables(...)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10448) org.apache.jackrabbit.api.security.user.Query must be a Consumer type
[
https://issues.apache.org/jira/browse/OAK-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765644#comment-17765644
]
Konrad Windszus commented on OAK-10448:
---
Fixed in
https://github.com/apache/jackrabbit-oak/commit/d4410fd1492acc687d38e6f041ca1e65c5efe483.
> org.apache.jackrabbit.api.security.user.Query must be a Consumer type
> -
>
> Key: OAK-10448
> URL: https://issues.apache.org/jira/browse/OAK-10448
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jackrabbit-api
>Affects Versions: 1.54.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> In the context of OAK-10252 the interface
> {{org.apache.jackrabbit.api.security.user.Query}} was incorrectly converted
> from implicit consumer type to provider type
> (https://github.com/apache/jackrabbit-oak/blob/dcd46825e21f373fda8dbfe61cdaeac522fe15eb/oak-jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/user/Query.java#L45).
> In fact this interface is supposed to be implemented by consumers (e.g.
> those leveraging
> {{org.apache.jackrabbit.api.security.user.UserManager#findAuthorizables(...)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10448) org.apache.jackrabbit.api.security.user.Query must be a Consumer type
[
https://issues.apache.org/jira/browse/OAK-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-10448:
--
Fix Version/s: 1.58.0
> org.apache.jackrabbit.api.security.user.Query must be a Consumer type
> -
>
> Key: OAK-10448
> URL: https://issues.apache.org/jira/browse/OAK-10448
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jackrabbit-api
>Affects Versions: 1.54.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 1.58.0
>
>
> In the context of OAK-10252 the interface
> {{org.apache.jackrabbit.api.security.user.Query}} was incorrectly converted
> from implicit consumer type to provider type
> (https://github.com/apache/jackrabbit-oak/blob/dcd46825e21f373fda8dbfe61cdaeac522fe15eb/oak-jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/user/Query.java#L45).
> In fact this interface is supposed to be implemented by consumers (e.g.
> those leveraging
> {{org.apache.jackrabbit.api.security.user.UserManager#findAuthorizables(...)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10448) org.apache.jackrabbit.api.security.user.Query must be a Consumer type
[
https://issues.apache.org/jira/browse/OAK-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765297#comment-17765297
]
Konrad Windszus commented on OAK-10448:
---
[~royteeuwen] For both {{org.apache.jackrabbit.api.security.user.Group}} and
{{org.apache.jackrabbit.api.security.user.Authorizable}} I disagree that those
should be Consumer type interfaces. They are IMHO correctly classified as
provider type and no consumer bundle of the Jackrabbit API should be
implementing those interfaces.
A workaround for the AEM specific limitation that only consumer types may be
implemented at all (which is not really related to the actual classification)
is to use something like dynamic proxies
(https://docs.oracle.com/javase/8/docs/technotes/guides/reflection/proxy.html).
> org.apache.jackrabbit.api.security.user.Query must be a Consumer type
> -
>
> Key: OAK-10448
> URL: https://issues.apache.org/jira/browse/OAK-10448
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jackrabbit-api
>Affects Versions: 1.54.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> In the context of OAK-10252 the interface
> {{org.apache.jackrabbit.api.security.user.Query}} was incorrectly converted
> from implicit consumer type to provider type
> (https://github.com/apache/jackrabbit-oak/blob/dcd46825e21f373fda8dbfe61cdaeac522fe15eb/oak-jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/user/Query.java#L45).
> In fact this interface is supposed to be implemented by consumers (e.g.
> those leveraging
> {{org.apache.jackrabbit.api.security.user.UserManager#findAuthorizables(...)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10448) org.apache.jackrabbit.api.security.user.Query must be a Consumer type
[
https://issues.apache.org/jira/browse/OAK-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765237#comment-17765237
]
Konrad Windszus commented on OAK-10448:
---
This causes the following downstream issue:
https://github.com/Netcentric/accesscontroltool/issues/671
> org.apache.jackrabbit.api.security.user.Query must be a Consumer type
> -
>
> Key: OAK-10448
> URL: https://issues.apache.org/jira/browse/OAK-10448
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jackrabbit-api
>Affects Versions: 1.54.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> In the context of OAK-10252 the interface
> {{org.apache.jackrabbit.api.security.user.Query}} was incorrectly converted
> from implicit consumer type to provider type
> (https://github.com/apache/jackrabbit-oak/blob/dcd46825e21f373fda8dbfe61cdaeac522fe15eb/oak-jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/user/Query.java#L45).
> In fact this interface is supposed to be implemented by consumers (e.g.
> those leveraging
> {{org.apache.jackrabbit.api.security.user.UserManager#findAuthorizables(...)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10448) org.apache.jackrabbit.api.security.user.Query must be a Consumer type
[
https://issues.apache.org/jira/browse/OAK-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-10448:
--
Description: In the context of OAK-10252 the interface
{{org.apache.jackrabbit.api.security.user.Query}} was incorrectly converted
from implicit consumer type to provider type
(https://github.com/apache/jackrabbit-oak/blob/dcd46825e21f373fda8dbfe61cdaeac522fe15eb/oak-jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/user/Query.java#L45).
In fact this interface is supposed to be implemented by consumers (e.g. those
leveraging
{{org.apache.jackrabbit.api.security.user.UserManager#findAuthorizables(...)}}
(was: In the context of OAK-10252 the interface
{{org.apache.jackrabbit.api.security.user.Query}} was incorrectly converted
from implicit consumer type to provider type. In fact this interface is
supposed to be implemented by consumers (e.g. those leveraging
{{org.apache.jackrabbit.api.security.user.UserManager#findAuthorizables(...)}})
> org.apache.jackrabbit.api.security.user.Query must be a Consumer type
> -
>
> Key: OAK-10448
> URL: https://issues.apache.org/jira/browse/OAK-10448
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jackrabbit-api
>Affects Versions: 1.54.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> In the context of OAK-10252 the interface
> {{org.apache.jackrabbit.api.security.user.Query}} was incorrectly converted
> from implicit consumer type to provider type
> (https://github.com/apache/jackrabbit-oak/blob/dcd46825e21f373fda8dbfe61cdaeac522fe15eb/oak-jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/user/Query.java#L45).
> In fact this interface is supposed to be implemented by consumers (e.g.
> those leveraging
> {{org.apache.jackrabbit.api.security.user.UserManager#findAuthorizables(...)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10448) org.apache.jackrabbit.api.security.user.Query must be a Consumer type
[
https://issues.apache.org/jira/browse/OAK-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-10448:
--
Description: In the context of OAK-10252 the interface
{{org.apache.jackrabbit.api.security.user.Query}} was incorrectly converted
from implicit consumer type to provider type. In fact this interface is
supposed to be implemented by consumers (e.g. those leveraging
{{org.apache.jackrabbit.api.security.user.UserManager#findAuthorizables(...)}}
(was: In the context of OAK-10252 the interface
`org.apache.jackrabbit.api.security.user.Query` was incorrectly converted from
implicit consumer type to provider type. In fact this interface is supposed to
be implemented by consumers (e.g. those leveraging
{{org.apache.jackrabbit.api.security.user.UserManager#findAuthorizables(...)}})
> org.apache.jackrabbit.api.security.user.Query must be a Consumer type
> -
>
> Key: OAK-10448
> URL: https://issues.apache.org/jira/browse/OAK-10448
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jackrabbit-api
>Affects Versions: 1.54.0
>Reporter: Konrad Windszus
>Priority: Major
>
> In the context of OAK-10252 the interface
> {{org.apache.jackrabbit.api.security.user.Query}} was incorrectly converted
> from implicit consumer type to provider type. In fact this interface is
> supposed to be implemented by consumers (e.g. those leveraging
> {{org.apache.jackrabbit.api.security.user.UserManager#findAuthorizables(...)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10448) org.apache.jackrabbit.api.security.user.Query must be a Consumer type
[
https://issues.apache.org/jira/browse/OAK-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned OAK-10448:
-
Assignee: Konrad Windszus
> org.apache.jackrabbit.api.security.user.Query must be a Consumer type
> -
>
> Key: OAK-10448
> URL: https://issues.apache.org/jira/browse/OAK-10448
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jackrabbit-api
>Affects Versions: 1.54.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> In the context of OAK-10252 the interface
> {{org.apache.jackrabbit.api.security.user.Query}} was incorrectly converted
> from implicit consumer type to provider type. In fact this interface is
> supposed to be implemented by consumers (e.g. those leveraging
> {{org.apache.jackrabbit.api.security.user.UserManager#findAuthorizables(...)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10448) org.apache.jackrabbit.api.security.user.Query must be a Consumer type
Konrad Windszus created OAK-10448:
-
Summary: org.apache.jackrabbit.api.security.user.Query must be a
Consumer type
Key: OAK-10448
URL: https://issues.apache.org/jira/browse/OAK-10448
Project: Jackrabbit Oak
Issue Type: Bug
Components: jackrabbit-api
Reporter: Konrad Windszus
In the context of OAK-10252 the interface
`org.apache.jackrabbit.api.security.user.Query` was incorrectly converted from
implicit consumer type to provider type. In fact this interface is supposed to
be implemented by consumers (e.g. those leveraging
{{org.apache.jackrabbit.api.security.user.UserManager#findAuthorizables(...)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10448) org.apache.jackrabbit.api.security.user.Query must be a Consumer type
[
https://issues.apache.org/jira/browse/OAK-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-10448:
--
Affects Version/s: 1.54.0
> org.apache.jackrabbit.api.security.user.Query must be a Consumer type
> -
>
> Key: OAK-10448
> URL: https://issues.apache.org/jira/browse/OAK-10448
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jackrabbit-api
>Affects Versions: 1.54.0
>Reporter: Konrad Windszus
>Priority: Major
>
> In the context of OAK-10252 the interface
> `org.apache.jackrabbit.api.security.user.Query` was incorrectly converted
> from implicit consumer type to provider type. In fact this interface is
> supposed to be implemented by consumers (e.g. those leveraging
> {{org.apache.jackrabbit.api.security.user.UserManager#findAuthorizables(...)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-9837) Reference individual OSGi dependencies in version shipped with R7
[
https://issues.apache.org/jira/browse/OAK-9837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747581#comment-17747581
]
Konrad Windszus commented on OAK-9837:
--
[~baedke] Thanks for digging into this. I applied your patch to my PR in
https://github.com/apache/jackrabbit-oak/pull/1015/commits/e3aefa5b7f3c38345709675d433104e1cae9bb9b.
> Reference individual OSGi dependencies in version shipped with R7
> -
>
> Key: OAK-9837
> URL: https://issues.apache.org/jira/browse/OAK-9837
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: parent
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 1.56.0
>
> Attachments: oak-9837-tests.patch
>
>
> Instead of the aggregate dependencies {{org.osgi.core}} and
> {{org.osgi.compendium}} rather the individual OSGi spec chapter dependencies
> should be used (http://docs.osgi.org/artifacts/). Those allow to version each
> spec chapter individually (independent from the Core/Compendium release). The
> earliest available versions are from OSGi R6 or R7 though (i.e. an update
> from the currently minimally required core/compendium 4.2 is required but
> shouldn't do any harm, as R6 is from 2015, i.e. already 7 years old)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-9837) Reference individual OSGi dependencies in version shipped with R7
[
https://issues.apache.org/jira/browse/OAK-9837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747500#comment-17747500
]
Konrad Windszus commented on OAK-9837:
--
Are those really related or just unstable ITs?
> Reference individual OSGi dependencies in version shipped with R7
> -
>
> Key: OAK-9837
> URL: https://issues.apache.org/jira/browse/OAK-9837
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: parent
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 1.56.0
>
>
> Instead of the aggregate dependencies {{org.osgi.core}} and
> {{org.osgi.compendium}} rather the individual OSGi spec chapter dependencies
> should be used (http://docs.osgi.org/artifacts/). Those allow to version each
> spec chapter individually (independent from the Core/Compendium release). The
> earliest available versions are from OSGi R6 or R7 though (i.e. an update
> from the currently minimally required core/compendium 4.2 is required but
> shouldn't do any harm, as R6 is from 2015, i.e. already 7 years old)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10332) Ease using o.a.j.o.spi.security.authorization.principalbased.impl.FilterProviderImpl outside OSGi containers
[
https://issues.apache.org/jira/browse/OAK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved OAK-10332.
---
Resolution: Fixed
Fixed in
https://github.com/apache/jackrabbit-oak/commit/03b703e91f9964a2f192ccd34526d5980561839a.
> Ease using
> o.a.j.o.spi.security.authorization.principalbased.impl.FilterProviderImpl
> outside OSGi containers
>
>
> Key: OAK-10332
> URL: https://issues.apache.org/jira/browse/OAK-10332
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: authorization-principalbased
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: 1.54.0
>
>
> Currently the only way to use
> https://github.com/apache/jackrabbit-oak/blob/25c01b81768c77e558078a92a31309910902f3a0/oak-authorization-principalbased/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/principalbased/impl/FilterProviderImpl.java#L62
> is by letting an OSGi Service Component runtime manage it. Outside OSGi
> containers the implementations cannot be reused as the only way to initialize
> it is calling the protected method {{activate(...)}} or the private method
> {{setPath(...)}}. Both expect a parameter of type
> {{FilterProviderImpl.Configuration}} which is not public either.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10327) Embedded dependencies should have "provided" scope
[
https://issues.apache.org/jira/browse/OAK-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved OAK-10327.
---
Fix Version/s: 1.54.0
Resolution: Fixed
Fixed in
https://github.com/apache/jackrabbit-oak/commit/9ea124cfbbf6cd94b52a074a367ae0d5e59cb498.
> Embedded dependencies should have "provided" scope
> --
>
> Key: OAK-10327
> URL: https://issues.apache.org/jira/browse/OAK-10327
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.52.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 1.54.0
>
>
> The embedded dependencies in {{oak-segment-tar}} should have {{provided}}
> scope in order to prevent them from being transitively inherited:
> https://github.com/apache/jackrabbit-oak/blob/05030fcba4275bfbf627b2c6786d05934cc9f791/oak-segment-tar/pom.xml#L292
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10339) Migrate to SLF4J 2.x
[
https://issues.apache.org/jira/browse/OAK-10339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-10339:
--
Description:
Update to SLF4J 2.x in order to use the fluent API.
Compare with SLING-11906 for a similar effort in Sling.
At the same time we should consider getting rid of dependencies to
{{org.slf4j.helpers}} and {{org.slf4j.event}} which are considered only
relevant for logging backends. Those versions are no longer exposed in a
backwards compatible version in SLF4J 2.x, the official 1.x API at
{{org.slf4j}} should still work even with 2.x API bundle and implementations.
was:
Update to SLF4J 2.x in order to use the fluent API.
Compare with SLING-11906 for a similar effort in Sling.
> Migrate to SLF4J 2.x
>
>
> Key: OAK-10339
> URL: https://issues.apache.org/jira/browse/OAK-10339
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: parent
>Reporter: Konrad Windszus
>Priority: Major
>
> Update to SLF4J 2.x in order to use the fluent API.
> Compare with SLING-11906 for a similar effort in Sling.
> At the same time we should consider getting rid of dependencies to
> {{org.slf4j.helpers}} and {{org.slf4j.event}} which are considered only
> relevant for logging backends. Those versions are no longer exposed in a
> backwards compatible version in SLF4J 2.x, the official 1.x API at
> {{org.slf4j}} should still work even with 2.x API bundle and implementations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10339) Migrate to SLF4J 2.x
Konrad Windszus created OAK-10339: - Summary: Migrate to SLF4J 2.x Key: OAK-10339 URL: https://issues.apache.org/jira/browse/OAK-10339 Project: Jackrabbit Oak Issue Type: Improvement Components: parent Reporter: Konrad Windszus Update to SLF4J 2.x in order to use the fluent API. Compare with SLING-11906 for a similar effort in Sling. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-9837) Reference individual OSGi dependencies in version shipped with R7
[
https://issues.apache.org/jira/browse/OAK-9837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-9837:
-
Fix Version/s: 1.54.0
> Reference individual OSGi dependencies in version shipped with R7
> -
>
> Key: OAK-9837
> URL: https://issues.apache.org/jira/browse/OAK-9837
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: parent
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 1.54.0
>
>
> Instead of the aggregate dependencies {{org.osgi.core}} and
> {{org.osgi.compendium}} rather the individual OSGi spec chapter dependencies
> should be used (http://docs.osgi.org/artifacts/). Those allow to version each
> spec chapter individually (independent from the Core/Compendium release). The
> earliest available versions are from OSGi R6 or R7 though (i.e. an update
> from the currently minimally required core/compendium 4.2 is required but
> shouldn't do any harm, as R6 is from 2015, i.e. already 7 years old)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10332) Ease using o.a.j.o.spi.security.authorization.principalbased.impl.FilterProviderImpl outside OSGi containers
[
https://issues.apache.org/jira/browse/OAK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-10332:
--
Fix Version/s: 1.54.0
> Ease using
> o.a.j.o.spi.security.authorization.principalbased.impl.FilterProviderImpl
> outside OSGi containers
>
>
> Key: OAK-10332
> URL: https://issues.apache.org/jira/browse/OAK-10332
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: authorization-principalbased
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: 1.54.0
>
>
> Currently the only way to use
> https://github.com/apache/jackrabbit-oak/blob/25c01b81768c77e558078a92a31309910902f3a0/oak-authorization-principalbased/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/principalbased/impl/FilterProviderImpl.java#L62
> is by letting an OSGi Service Component runtime manage it. Outside OSGi
> containers the implementations cannot be reused as the only way to initialize
> it is calling the protected method {{activate(...)}} or the private method
> {{setPath(...)}}. Both expect a parameter of type
> {{FilterProviderImpl.Configuration}} which is not public either.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-9837) Reference individual OSGi dependencies in version shipped with R7
[
https://issues.apache.org/jira/browse/OAK-9837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned OAK-9837:
Assignee: Konrad Windszus
> Reference individual OSGi dependencies in version shipped with R7
> -
>
> Key: OAK-9837
> URL: https://issues.apache.org/jira/browse/OAK-9837
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: parent
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Instead of the aggregate dependencies {{org.osgi.core}} and
> {{org.osgi.compendium}} rather the individual OSGi spec chapter dependencies
> should be used (http://docs.osgi.org/artifacts/). Those allow to version each
> spec chapter individually (independent from the Core/Compendium release). The
> earliest available versions are from OSGi R6 or R7 though (i.e. an update
> from the currently minimally required core/compendium 4.2 is required but
> shouldn't do any harm, as R6 is from 2015, i.e. already 7 years old)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10332) Ease using o.a.j.o.spi.security.authorization.principalbased.impl.FilterProviderImpl outside OSGi containers
[
https://issues.apache.org/jira/browse/OAK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned OAK-10332:
-
Assignee: Konrad Windszus
> Ease using
> o.a.j.o.spi.security.authorization.principalbased.impl.FilterProviderImpl
> outside OSGi containers
>
>
> Key: OAK-10332
> URL: https://issues.apache.org/jira/browse/OAK-10332
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: authorization-principalbased
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Minor
>
> Currently the only way to use
> https://github.com/apache/jackrabbit-oak/blob/25c01b81768c77e558078a92a31309910902f3a0/oak-authorization-principalbased/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/principalbased/impl/FilterProviderImpl.java#L62
> is by letting an OSGi Service Component runtime manage it. Outside OSGi
> containers the implementations cannot be reused as the only way to initialize
> it is calling the protected method {{activate(...)}} or the private method
> {{setPath(...)}}. Both expect a parameter of type
> {{FilterProviderImpl.Configuration}} which is not public either.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-9837) Reference individual OSGi dependencies in version shipped with R7
[
https://issues.apache.org/jira/browse/OAK-9837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-9837:
-
Summary: Reference individual OSGi dependencies in version shipped with R7
(was: Reference individual OSGi dependencies)
> Reference individual OSGi dependencies in version shipped with R7
> -
>
> Key: OAK-9837
> URL: https://issues.apache.org/jira/browse/OAK-9837
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: parent
>Reporter: Konrad Windszus
>Priority: Major
>
> Instead of the aggregate dependencies {{org.osgi.core}} and
> {{org.osgi.compendium}} rather the individual OSGi spec chapter dependencies
> should be used (http://docs.osgi.org/artifacts/). Those allow to version each
> spec chapter individually (independent from the Core/Compendium release). The
> earliest available versions are from OSGi R6 or R7 though (i.e. an update
> from the currently minimally required core/compendium 4.2 is required but
> shouldn't do any harm, as R6 is from 2015, i.e. already 7 years old)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-9837) Reference individual OSGi dependencies
[
https://issues.apache.org/jira/browse/OAK-9837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739587#comment-17739587
]
Konrad Windszus commented on OAK-9837:
--
Related discussion started in
https://lists.apache.org/thread/6h3vdpcv85xk7pw435t6lg7jo396x1t5.
> Reference individual OSGi dependencies
> --
>
> Key: OAK-9837
> URL: https://issues.apache.org/jira/browse/OAK-9837
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: parent
>Reporter: Konrad Windszus
>Priority: Major
>
> Instead of the aggregate dependencies {{org.osgi.core}} and
> {{org.osgi.compendium}} rather the individual OSGi spec chapter dependencies
> should be used (http://docs.osgi.org/artifacts/). Those allow to version each
> spec chapter individually (independent from the Core/Compendium release). The
> earliest available versions are from OSGi R6 or R7 though (i.e. an update
> from the currently minimally required core/compendium 4.2 is required but
> shouldn't do any harm, as R6 is from 2015, i.e. already 7 years old)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-9292) Fix links to Jackrabbit API
[ https://issues.apache.org/jira/browse/OAK-9292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved OAK-9292. -- Resolution: Fixed This has been fixed already quite some time ago. > Fix links to Jackrabbit API > --- > > Key: OAK-9292 > URL: https://issues.apache.org/jira/browse/OAK-9292 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: docs >Reporter: Konrad Windszus >Priority: Major > > The page at https://jackrabbit.apache.org/oak/docs/oak_api/overview.html > (https://github.com/apache/jackrabbit-oak/blob/trunk/oak-doc/src/site/markdown/oak_api/overview.md) > as well as the sidebar > (https://github.com/apache/jackrabbit-oak/blob/069f1b025b9bcc971221cb222c6e19c2cdeb704e/oak-doc/src/site/site.xml#L40) > lack links to the proper jackrabbit API javadoc which is now accessible at > https://www.javadoc.io/doc/org.apache.jackrabbit/oak-jackrabbit-api/latest/index.html > or at https://jackrabbit.apache.org/oak/docs/apidocs/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10332) Ease using o.a.j.o.spi.security.authorization.principalbased.impl.FilterProviderImpl outside OSGi containers
Konrad Windszus created OAK-10332:
-
Summary: Ease using
o.a.j.o.spi.security.authorization.principalbased.impl.FilterProviderImpl
outside OSGi containers
Key: OAK-10332
URL: https://issues.apache.org/jira/browse/OAK-10332
Project: Jackrabbit Oak
Issue Type: Improvement
Components: authorization-principalbased
Reporter: Konrad Windszus
Currently the only way to use
https://github.com/apache/jackrabbit-oak/blob/25c01b81768c77e558078a92a31309910902f3a0/oak-authorization-principalbased/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/principalbased/impl/FilterProviderImpl.java#L62
is by letting an OSGi Service Component runtime manage it. Outside OSGi
containers the implementations cannot be reused as the only way to initialize
it is calling the protected method {{activate(...)}} or the private method
{{setPath(...)}}. Both expect a parameter of type
{{FilterProviderImpl.Configuration}} which is not public either.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10328) jackrabbit-jcr-tests should have scope "tests"
[
https://issues.apache.org/jira/browse/OAK-10328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved OAK-10328.
---
Fix Version/s: 1.54.0
Resolution: Fixed
Fixed in
https://github.com/apache/jackrabbit-oak/commit/667e2d234bf0e242f4a1439e04cea1e95a2cbbc5.
> jackrabbit-jcr-tests should have scope "tests"
> --
>
> Key: OAK-10328
> URL: https://issues.apache.org/jira/browse/OAK-10328
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.52.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 1.54.0
>
>
> Currently the dependency {{jackrabbit-jcr-tests}} in {{oak-jcr}} have the
> default scope ({{compile}}):
> https://github.com/apache/jackrabbit-oak/blob/05030fcba4275bfbf627b2c6786d05934cc9f791/oak-jcr/pom.xml#L424.
> In order to prevent that from being transitively inherited it should have
> scope {{test}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10328) jackrabbit-jcr-tests should have scope "tests"
Konrad Windszus created OAK-10328:
-
Summary: jackrabbit-jcr-tests should have scope "tests"
Key: OAK-10328
URL: https://issues.apache.org/jira/browse/OAK-10328
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Affects Versions: 1.52.0
Reporter: Konrad Windszus
Currently the dependency {{jackrabbit-jcr-tests}} in {{oak-jcr}} have the
default scope ({{compile}}):
https://github.com/apache/jackrabbit-oak/blob/05030fcba4275bfbf627b2c6786d05934cc9f791/oak-jcr/pom.xml#L424.
In order to prevent that from being transitively inherited it should have
scope {{test}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10328) jackrabbit-jcr-tests should have scope "tests"
[
https://issues.apache.org/jira/browse/OAK-10328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned OAK-10328:
-
Assignee: Konrad Windszus
> jackrabbit-jcr-tests should have scope "tests"
> --
>
> Key: OAK-10328
> URL: https://issues.apache.org/jira/browse/OAK-10328
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.52.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the dependency {{jackrabbit-jcr-tests}} in {{oak-jcr}} have the
> default scope ({{compile}}):
> https://github.com/apache/jackrabbit-oak/blob/05030fcba4275bfbf627b2c6786d05934cc9f791/oak-jcr/pom.xml#L424.
> In order to prevent that from being transitively inherited it should have
> scope {{test}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10327) Embedded dependencies should have "provided" scope
[
https://issues.apache.org/jira/browse/OAK-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned OAK-10327:
-
Assignee: Konrad Windszus
> Embedded dependencies should have "provided" scope
> --
>
> Key: OAK-10327
> URL: https://issues.apache.org/jira/browse/OAK-10327
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.52.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The embedded dependencies in {{oak-segment-tar}} should have {{provided}}
> scope in order to prevent them from being transitively inherited:
> https://github.com/apache/jackrabbit-oak/blob/05030fcba4275bfbf627b2c6786d05934cc9f791/oak-segment-tar/pom.xml#L292
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10327) Embedded dependencies should have "provided" scope
Konrad Windszus created OAK-10327:
-
Summary: Embedded dependencies should have "provided" scope
Key: OAK-10327
URL: https://issues.apache.org/jira/browse/OAK-10327
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segment-tar
Affects Versions: 1.52.0
Reporter: Konrad Windszus
The embedded dependencies in {{oak-segment-tar}} should have {{provided}} scope
in order to prevent them from being transitively inherited:
https://github.com/apache/jackrabbit-oak/blob/05030fcba4275bfbf627b2c6786d05934cc9f791/oak-segment-tar/pom.xml#L292
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10305) oak-core should changes scope of annotation dependencies to provided
[
https://issues.apache.org/jira/browse/OAK-10305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved OAK-10305.
---
Fix Version/s: 1.54.0
Resolution: Fixed
Fixed in
https://github.com/apache/jackrabbit-oak/commit/ff0bf210fcdd5256c9f69fcf28b64c26e134b2f4.
> oak-core should changes scope of annotation dependencies to provided
>
>
> Key: OAK-10305
> URL: https://issues.apache.org/jira/browse/OAK-10305
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.52.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 1.54.0
>
>
> Currently both {{org.osgi.service.component.annotations}} and
> {{org.osgi.service.metatype.annotations}} have the default scope {{compile}}
> which makes this dependency transitively available to dependent Maven
> modules.
> As those annotations are only relevant at build time they should always be
> used with scope {{provided}} in order to prevent them to be transitively
> inherited.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10305) oak-core should changes scope of annotation dependencies to provided
[
https://issues.apache.org/jira/browse/OAK-10305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-10305:
--
Description:
Currently both {{org.osgi.service.component.annotations}} and
{{org.osgi.service.metatype.annotations}} have the default scope {{compile}}
which makes this dependency transitively available to dependent Maven modules.
As those annotations are only relevant at build time they should always be used
with scope {{provided}} in order to prevent them to be transitively inherited.
was:
Currently both {{org.osgi.service.component.annotations}} and
{{org.osgi.service.metatype.annotations}} have the default scope {{compile}}
which makes this dependency transitively available to dependent Maven modules.
As those annotations are only relevant at build time they should always be used
with scope {{provided}}.
> oak-core should changes scope of annotation dependencies to provided
>
>
> Key: OAK-10305
> URL: https://issues.apache.org/jira/browse/OAK-10305
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.52.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently both {{org.osgi.service.component.annotations}} and
> {{org.osgi.service.metatype.annotations}} have the default scope {{compile}}
> which makes this dependency transitively available to dependent Maven
> modules.
> As those annotations are only relevant at build time they should always be
> used with scope {{provided}} in order to prevent them to be transitively
> inherited.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10305) oak-core should changes scope of annotation dependencies to provided
Konrad Windszus created OAK-10305:
-
Summary: oak-core should changes scope of annotation dependencies
to provided
Key: OAK-10305
URL: https://issues.apache.org/jira/browse/OAK-10305
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Affects Versions: 1.52.0
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Currently both {{org.osgi.service.component.annotations}} and
{{org.osgi.service.metatype.annotations}} have the default scope {{compile}}
which makes this dependency transitively available to dependent Maven modules.
As those annotations are only relevant at build time they should always be used
with scope {{provided}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10252) Distinguish in oak-jackrabbit-api between provider and consumer type interfaces
[ https://issues.apache.org/jira/browse/OAK-10252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated OAK-10252: -- Description: Currently there is almost no annotation related to Provider or Consumer type maintained on the interfaces of https://github.com/apache/jackrabbit-oak/tree/trunk/oak-jackrabbit-api. That leads to a default of almost all interfaces being assumed ConsumerType and therefore requiring all backwards-incompatible changes (for implementations) a major version increment (which breaks every consuming bundle). For ProviderType interfaces (https://docs.osgi.org/javadoc/osgi.annotation/7.0.0/org/osgi/annotation/versioning/ProviderType.html) bq. A non-binary-compatible change to a provider type normally requires incrementing the major version of the type's package. This change will require all providers and all consumers to be updated to handle the change. However, a non-binary-compatible change affecting a protected access member only requires incrementing the minor version of the type's package. This change will require all providers to be updated to handle the change, but consumers will not require changes since they only use, and do not extend, the provider type and thus could not access protected access members of the provider type. While for ConsumerType interfaces (the default) (https://docs.osgi.org/javadoc/osgi.annotation/7.0.0/org/osgi/annotation/versioning/ConsumerType.html) bq. A non-binary-compatible change to a consumer type or a binary-compatible change to a consumer type affecting an abstract method normally requires incrementing the major version of the type's package. This change will require all providers and all consumers to be updated to handle the change since consumers that implement or extend the consumer type and all providers must understand the change in the consumer type. was: Currently there is no annotation related to Provider or Consumer type maintained on the interfaces of https://github.com/apache/jackrabbit-oak/tree/trunk/oak-jackrabbit-api. That leads to a default of all interfaces being assumed ConsumerType and therefore requiring all backwards-incompatible changes a major version increment (which breaks every consuming bundle). For ProviderType interfaces (https://docs.osgi.org/javadoc/osgi.annotation/7.0.0/org/osgi/annotation/versioning/ProviderType.html) bq. A non-binary-compatible change to a provider type normally requires incrementing the major version of the type's package. This change will require all providers and all consumers to be updated to handle the change. However, a non-binary-compatible change affecting a protected access member only requires incrementing the minor version of the type's package. This change will require all providers to be updated to handle the change, but consumers will not require changes since they only use, and do not extend, the provider type and thus could not access protected access members of the provider type. While for ConsumerType interfaces (the default) (https://docs.osgi.org/javadoc/osgi.annotation/7.0.0/org/osgi/annotation/versioning/ConsumerType.html) bq. A non-binary-compatible change to a consumer type or a binary-compatible change to a consumer type affecting an abstract method normally requires incrementing the major version of the type's package. This change will require all providers and all consumers to be updated to handle the change since consumers that implement or extend the consumer type and all providers must understand the change in the consumer type. > Distinguish in oak-jackrabbit-api between provider and consumer type > interfaces > --- > > Key: OAK-10252 > URL: https://issues.apache.org/jira/browse/OAK-10252 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jackrabbit-api >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Currently there is almost no annotation related to Provider or Consumer type > maintained on the interfaces of > https://github.com/apache/jackrabbit-oak/tree/trunk/oak-jackrabbit-api. > That leads to a default of almost all interfaces being assumed ConsumerType > and therefore requiring all backwards-incompatible changes (for > implementations) a major version increment (which breaks every consuming > bundle). > For ProviderType interfaces > (https://docs.osgi.org/javadoc/osgi.annotation/7.0.0/org/osgi/annotation/versioning/ProviderType.html) > bq. A non-binary-compatible change to a provider type normally requires > incrementing the major version of the type's package. This change will > require all providers and all consumers to be updated to handle the change. > However, a non-binary-compatible change affecting a
[jira] [Assigned] (OAK-10252) Distinguish in oak-jackrabbit-api between provider and consumer type interfaces
[ https://issues.apache.org/jira/browse/OAK-10252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned OAK-10252: - Assignee: Konrad Windszus > Distinguish in oak-jackrabbit-api between provider and consumer type > interfaces > --- > > Key: OAK-10252 > URL: https://issues.apache.org/jira/browse/OAK-10252 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jackrabbit-api >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Currently there is no annotation related to Provider or Consumer type > maintained on the interfaces of > https://github.com/apache/jackrabbit-oak/tree/trunk/oak-jackrabbit-api. > That leads to a default of all interfaces being assumed ConsumerType and > therefore requiring all backwards-incompatible changes a major version > increment (which breaks every consuming bundle). > For ProviderType interfaces > (https://docs.osgi.org/javadoc/osgi.annotation/7.0.0/org/osgi/annotation/versioning/ProviderType.html) > bq. A non-binary-compatible change to a provider type normally requires > incrementing the major version of the type's package. This change will > require all providers and all consumers to be updated to handle the change. > However, a non-binary-compatible change affecting a protected access member > only requires incrementing the minor version of the type's package. This > change will require all providers to be updated to handle the change, but > consumers will not require changes since they only use, and do not extend, > the provider type and thus could not access protected access members of the > provider type. > While for ConsumerType interfaces (the default) > (https://docs.osgi.org/javadoc/osgi.annotation/7.0.0/org/osgi/annotation/versioning/ConsumerType.html) > bq. A non-binary-compatible change to a consumer type or a binary-compatible > change to a consumer type affecting an abstract method normally requires > incrementing the major version of the type's package. This change will > require all providers and all consumers to be updated to handle the change > since consumers that implement or extend the consumer type and all providers > must understand the change in the consumer type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10252) Distinguish in oak-jackrabbit-api between provider and consumer type interfaces
Konrad Windszus created OAK-10252: - Summary: Distinguish in oak-jackrabbit-api between provider and consumer type interfaces Key: OAK-10252 URL: https://issues.apache.org/jira/browse/OAK-10252 Project: Jackrabbit Oak Issue Type: Improvement Components: jackrabbit-api Reporter: Konrad Windszus Currently there is no annotation related to Provider or Consumer type maintained on the interfaces of https://github.com/apache/jackrabbit-oak/tree/trunk/oak-jackrabbit-api. That leads to a default of all interfaces being assumed ConsumerType and therefore requiring all backwards-incompatible changes a major version increment (which breaks every consuming bundle). For ProviderType interfaces (https://docs.osgi.org/javadoc/osgi.annotation/7.0.0/org/osgi/annotation/versioning/ProviderType.html) bq. A non-binary-compatible change to a provider type normally requires incrementing the major version of the type's package. This change will require all providers and all consumers to be updated to handle the change. However, a non-binary-compatible change affecting a protected access member only requires incrementing the minor version of the type's package. This change will require all providers to be updated to handle the change, but consumers will not require changes since they only use, and do not extend, the provider type and thus could not access protected access members of the provider type. While for ConsumerType interfaces (the default) (https://docs.osgi.org/javadoc/osgi.annotation/7.0.0/org/osgi/annotation/versioning/ConsumerType.html) bq. A non-binary-compatible change to a consumer type or a binary-compatible change to a consumer type affecting an abstract method normally requires incrementing the major version of the type's package. This change will require all providers and all consumers to be updated to handle the change since consumers that implement or extend the consumer type and all providers must understand the change in the consumer type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10251) Introduce semantic versioning on package level for oak-jackrabbit-api
[ https://issues.apache.org/jira/browse/OAK-10251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved OAK-10251. --- Resolution: Invalid Sorry for the noise, this is already done since a long time. > Introduce semantic versioning on package level for oak-jackrabbit-api > - > > Key: OAK-10251 > URL: https://issues.apache.org/jira/browse/OAK-10251 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jackrabbit-api >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Currently the export-package statements being generated for > https://github.com/apache/jackrabbit-oak/tree/trunk/oak-jackrabbit-api are > not versioned (i.e. have implicitly version 0.0.0). That prevents consumers > from generating proper OSGi [version > ranges|https://docs.osgi.org/whitepaper/semantic-versioning/060-importer-policy.html], > instead they just import the package without any version directive. > That makes it much harder to detect backwards-compatibility issues and almost > impossible to introduce non-backwards compatible changes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10251) Introduce semantic versioning on package level for oak-jackrabbit-api
[ https://issues.apache.org/jira/browse/OAK-10251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned OAK-10251: - Assignee: Konrad Windszus > Introduce semantic versioning on package level for oak-jackrabbit-api > - > > Key: OAK-10251 > URL: https://issues.apache.org/jira/browse/OAK-10251 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jackrabbit-api >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Currently the export-package statements being generated for > https://github.com/apache/jackrabbit-oak/tree/trunk/oak-jackrabbit-api are > not versioned (i.e. have implicitly version 0.0.0). That prevents consumers > from generating proper OSGi [version > ranges|https://docs.osgi.org/whitepaper/semantic-versioning/060-importer-policy.html], > instead they just import the package without any version directive. > That makes it much harder to detect backwards-compatibility issues and almost > impossible to introduce non-backwards compatible changes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10251) Introduce semantic versioning on package level for oak-jackrabbit-api
Konrad Windszus created OAK-10251: - Summary: Introduce semantic versioning on package level for oak-jackrabbit-api Key: OAK-10251 URL: https://issues.apache.org/jira/browse/OAK-10251 Project: Jackrabbit Oak Issue Type: Improvement Components: jackrabbit-api Reporter: Konrad Windszus Currently the export-package statements being generated for https://github.com/apache/jackrabbit-oak/tree/trunk/oak-jackrabbit-api are not versioned (i.e. have implicitly version 0.0.0). That prevents consumers from generating proper OSGi [version ranges|https://docs.osgi.org/whitepaper/semantic-versioning/060-importer-policy.html], instead they just import the package without any version directive. That makes it much harder to detect backwards-compatibility issues and almost impossible to introduce non-backwards compatible changes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10228) Explain effect of policies for unknown principals and non-existing paths
[ https://issues.apache.org/jira/browse/OAK-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved OAK-10228. --- Assignee: Konrad Windszus Resolution: Fixed Fixed in https://github.com/apache/jackrabbit-oak/commit/fe23488d124f840bb4c4b1127affbf2670bd1084. > Explain effect of policies for unknown principals and non-existing paths > > > Key: OAK-10228 > URL: https://issues.apache.org/jira/browse/OAK-10228 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: doc, security >Reporter: Angela Schreiber >Assignee: Konrad Windszus >Priority: Trivial > > see > https://markmail.org/message/ptm44eikguudorh7?q=oak-dev+list:org%2Eapache%2Ejackrabbit%2Eoak-dev+from:%22Konrad+Windszus%22+order:date-backward=1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10051) META-INF/MANIFEST.MF is missing the Main-Class entry
[
https://issues.apache.org/jira/browse/OAK-10051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved OAK-10051.
---
Fix Version/s: 1.48.0
Assignee: Konrad Windszus
Resolution: Fixed
Fixed in
https://github.com/apache/jackrabbit-oak/commit/af958d39ce6ce3e03434276a917de4ad94f6b5ca.
> META-INF/MANIFEST.MF is missing the Main-Class entry
>
>
> Key: OAK-10051
> URL: https://issues.apache.org/jira/browse/OAK-10051
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run, upgrade
>Affects Versions: 1.46.0
>Reporter: Torsten Stolpmann
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 1.48.0
>
>
> This is a regression from 1.44.0 and previous versions, where the entry was
> still present.
>
> Without this entry it is no longer possible to use
> {{java - jar oak-run.jar}}
> and
> {{java - jar oak-upgrade.jar}}
> CLI invocations directly.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10052) Support authorization restriction based on mixin types
Konrad Windszus created OAK-10052:
-
Summary: Support authorization restriction based on mixin types
Key: OAK-10052
URL: https://issues.apache.org/jira/browse/OAK-10052
Project: Jackrabbit Oak
Issue Type: Improvement
Components: security
Reporter: Konrad Windszus
Currently there is only the restriction {{nt:Names}} which just considers
primary (non-effective) node types
(https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#built-in-restrictions).
In addition it should be supported to restrict access based on the mixin types.
The use case is e.g. Sling i18n dictionaries which leverage the mixin
{{mix:language}}
(https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html#jcr-repository-based-resourcebundleprovider).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10051) META-INF/MANIFEST.MF is missing the Main-Class entry
[
https://issues.apache.org/jira/browse/OAK-10051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652156#comment-17652156
]
Konrad Windszus commented on OAK-10051:
---
I am wondering why
https://github.com/apache/maven-assembly-plugin/blob/f42194b6c0e49bedad506821e524be076e839a79/src/main/java/org/apache/maven/plugins/assembly/mojos/AbstractAssemblyMojo.java#L560
doesn’t seem to be executed.
> META-INF/MANIFEST.MF is missing the Main-Class entry
>
>
> Key: OAK-10051
> URL: https://issues.apache.org/jira/browse/OAK-10051
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run, upgrade
>Affects Versions: 1.46.0
>Reporter: Torsten Stolpmann
>Priority: Major
>
> This is a regression from 1.44.0 and previous versions, where the entry was
> still present.
>
> Without this entry it is no longer possible to use
> {{java - jar oak-run.jar}}
> and
> {{java - jar oak-upgrade.jar}}
> CLI invocations directly.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10032) release:perform (or install -Papache-release) fails in oak-run
[
https://issues.apache.org/jira/browse/OAK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648345#comment-17648345
]
Konrad Windszus edited comment on OAK-10032 at 12/16/22 6:08 AM:
-
After having a 2nd thought a solution which doesn’t require the ant plugin to
replace the primary maven artifact would be even better. That should be
feasible by configuring m-assembly-p with
https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#appendassemblyid
to false. Will update my PR soon.
Update: Proposed as outlined above in new
https://github.com/apache/jackrabbit-oak/pull/794.
was (Author: kwin):
After having a 2nd thought a solution which doesn’t require the ant plugin to
replace the primary maven artifact would be even better. That should be
feasible by configuring m-assembly-p with
https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#appendassemblyid
to false. Will update my PR soon
> release:perform (or install -Papache-release) fails in oak-run
> --
>
> Key: OAK-10032
> URL: https://issues.apache.org/jira/browse/OAK-10032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Nitin Gupta
>Priority: Critical
> Fix For: 1.46.0
>
> Attachments: oak-run-effective-pom-after.xml,
> oak-run-effective-pom-before.xml
>
>
> With diagnostics:
> {noformat}
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (default) on project
> oak-run: An Ant BuildException has occured: Warning: Could not find file
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar
> to copy.
> [INFO] [ERROR] around Ant part ... file="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar"
>
> tofile="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0.jar"
> />... @ 4:231 in
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/antrun/build-main.xml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10032) release:perform (or install -Papache-release) fails in oak-run
[
https://issues.apache.org/jira/browse/OAK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648345#comment-17648345
]
Konrad Windszus commented on OAK-10032:
---
After having a 2nd thought a solution which doesn’t require the ant plugin to
replace the primary maven artifact would be even better. That should be
feasible by configuring m-assembly-p with
https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#appendassemblyid
to false. Will update my PR soon
> release:perform (or install -Papache-release) fails in oak-run
> --
>
> Key: OAK-10032
> URL: https://issues.apache.org/jira/browse/OAK-10032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Nitin Gupta
>Priority: Critical
> Fix For: 1.46.0
>
> Attachments: oak-run-effective-pom-after.xml,
> oak-run-effective-pom-before.xml
>
>
> With diagnostics:
> {noformat}
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (default) on project
> oak-run: An Ant BuildException has occured: Warning: Could not find file
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar
> to copy.
> [INFO] [ERROR] around Ant part ... file="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar"
>
> tofile="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0.jar"
> />... @ 4:231 in
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/antrun/build-main.xml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10032) release:perform fails in oak-run
[
https://issues.apache.org/jira/browse/OAK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648248#comment-17648248
]
Konrad Windszus edited comment on OAK-10032 at 12/15/22 9:14 PM:
-
In https://github.com/apache/jackrabbit-oak/pull/793 I came up with a fix which
assigns those goals to separate phases in order to no longer rely on internal
details of Maven, as according to
https://issues.apache.org/jira/browse/MNG-5987?focusedCommentId=15360031=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15360031
bq. it was documented and chosen that order of execution is not something you
cannot count on: phases are ordered, mojos in a phase simply are not
was (Author: kwin):
In https://github.com/apache/jackrabbit-oak/pull/793 I came up with a fix which
assigns those plugins separate phases to no longer rely on internal details of
Maven, as according to
https://issues.apache.org/jira/browse/MNG-5987?focusedCommentId=15360031=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15360031
bq. it was documented and chosen that order of execution is not something you
cannot count on: phases are ordered, mojos in a phase simply are not
> release:perform fails in oak-run
>
>
> Key: OAK-10032
> URL: https://issues.apache.org/jira/browse/OAK-10032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Nitin Gupta
>Priority: Critical
> Fix For: 1.46.0
>
> Attachments: oak-run-effective-pom-after.xml,
> oak-run-effective-pom-before.xml
>
>
> With diagnostics:
> {noformat}
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (default) on project
> oak-run: An Ant BuildException has occured: Warning: Could not find file
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar
> to copy.
> [INFO] [ERROR] around Ant part ... file="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar"
>
> tofile="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0.jar"
> />... @ 4:231 in
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/antrun/build-main.xml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10032) release:perform (or install -Papache-release) fails in oak-run
[
https://issues.apache.org/jira/browse/OAK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-10032:
--
Summary: release:perform (or install -Papache-release) fails in oak-run
(was: release:perform fails in oak-run)
> release:perform (or install -Papache-release) fails in oak-run
> --
>
> Key: OAK-10032
> URL: https://issues.apache.org/jira/browse/OAK-10032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Nitin Gupta
>Priority: Critical
> Fix For: 1.46.0
>
> Attachments: oak-run-effective-pom-after.xml,
> oak-run-effective-pom-before.xml
>
>
> With diagnostics:
> {noformat}
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (default) on project
> oak-run: An Ant BuildException has occured: Warning: Could not find file
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar
> to copy.
> [INFO] [ERROR] around Ant part ... file="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar"
>
> tofile="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0.jar"
> />... @ 4:231 in
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/antrun/build-main.xml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10032) release:perform fails in oak-run
[
https://issues.apache.org/jira/browse/OAK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648248#comment-17648248
]
Konrad Windszus commented on OAK-10032:
---
In https://github.com/apache/jackrabbit-oak/pull/793 I came up with a fix which
assigns those plugins separate phases to no longer rely on internal details of
Maven, as according to
https://issues.apache.org/jira/browse/MNG-5987?focusedCommentId=15360031=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15360031
bq. it was documented and chosen that order of execution is not something you
cannot count on: phases are ordered, mojos in a phase simply are not
> release:perform fails in oak-run
>
>
> Key: OAK-10032
> URL: https://issues.apache.org/jira/browse/OAK-10032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Nitin Gupta
>Priority: Critical
> Fix For: 1.46.0
>
> Attachments: oak-run-effective-pom-after.xml,
> oak-run-effective-pom-before.xml
>
>
> With diagnostics:
> {noformat}
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (default) on project
> oak-run: An Ant BuildException has occured: Warning: Could not find file
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar
> to copy.
> [INFO] [ERROR] around Ant part ... file="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar"
>
> tofile="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0.jar"
> />... @ 4:231 in
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/antrun/build-main.xml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10032) release:perform fails in oak-run
[
https://issues.apache.org/jira/browse/OAK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648244#comment-17648244
]
Konrad Windszus edited comment on OAK-10032 at 12/15/22 8:58 PM:
-
I attached both effective poms (with profile apache-release) and indeed the
order is somehow different:
[^oak-run-effective-pom-after.xml] vs [^oak-run-effective-pom-before.xml].
However in both effective poms the plugins are declared in order first antrun
then assembly (which is the reverse of what it should be).
Still not sure what had that effect (seems to be related to some version no
longer being overwritten from asf parent but just inherited).
was (Author: kwin):
I attached both effective poms (with profile apache-release) and indeed the
order is somehow different:
[^oak-run-effective-pom-after.xml] vs [^oak-run-effective-pom-before.xml].
Still not sure what had that effect (seems to be related to some version no
longer being overwritten from asf parent but just inherited).
> release:perform fails in oak-run
>
>
> Key: OAK-10032
> URL: https://issues.apache.org/jira/browse/OAK-10032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Nitin Gupta
>Priority: Critical
> Fix For: 1.46.0
>
> Attachments: oak-run-effective-pom-after.xml,
> oak-run-effective-pom-before.xml
>
>
> With diagnostics:
> {noformat}
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (default) on project
> oak-run: An Ant BuildException has occured: Warning: Could not find file
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar
> to copy.
> [INFO] [ERROR] around Ant part ... file="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar"
>
> tofile="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0.jar"
> />... @ 4:231 in
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/antrun/build-main.xml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10032) release:perform fails in oak-run
[
https://issues.apache.org/jira/browse/OAK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648244#comment-17648244
]
Konrad Windszus commented on OAK-10032:
---
I attached both effective poms (with profile apache-release) and indeed the
order is somehow different:
[^oak-run-effective-pom-after.xml] vs [^oak-run-effective-pom-before.xml].
Still not sure what had that effect (seems to be related to some version no
longer being overwritten from asf parent but just inherited).
> release:perform fails in oak-run
>
>
> Key: OAK-10032
> URL: https://issues.apache.org/jira/browse/OAK-10032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Nitin Gupta
>Priority: Critical
> Fix For: 1.46.0
>
> Attachments: oak-run-effective-pom-after.xml,
> oak-run-effective-pom-before.xml
>
>
> With diagnostics:
> {noformat}
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (default) on project
> oak-run: An Ant BuildException has occured: Warning: Could not find file
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar
> to copy.
> [INFO] [ERROR] around Ant part ... file="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar"
>
> tofile="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0.jar"
> />... @ 4:231 in
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/antrun/build-main.xml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10032) release:perform fails in oak-run
[
https://issues.apache.org/jira/browse/OAK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-10032:
--
Attachment: oak-run-effective-pom-after.xml
oak-run-effective-pom-before.xml
> release:perform fails in oak-run
>
>
> Key: OAK-10032
> URL: https://issues.apache.org/jira/browse/OAK-10032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Nitin Gupta
>Priority: Critical
> Fix For: 1.46.0
>
> Attachments: oak-run-effective-pom-after.xml,
> oak-run-effective-pom-before.xml
>
>
> With diagnostics:
> {noformat}
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (default) on project
> oak-run: An Ant BuildException has occured: Warning: Could not find file
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar
> to copy.
> [INFO] [ERROR] around Ant part ... file="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar"
>
> tofile="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0.jar"
> />... @ 4:231 in
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/antrun/build-main.xml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10032) release:perform fails in oak-run
[
https://issues.apache.org/jira/browse/OAK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648228#comment-17648228
]
Konrad Windszus edited comment on OAK-10032 at 12/15/22 8:31 PM:
-
The problem is the order of execution: Without profile {{apache-release}} it is
first {{maven-assembly-plugin}} and then {{maven-antrun-plugin}} (for goals
bound to the same phase), with the profile it is the other way around.
Unfortunately both bind with their executions in
#
https://github.com/apache/jackrabbit-oak/blob/56a0fa0828e42b59089d014a20dff3b378d8edc9/oak-run/pom.xml#L102
and
#
https://github.com/apache/jackrabbit-oak/blob/56a0fa0828e42b59089d014a20dff3b378d8edc9/oak-run/pom.xml#L120
to the same phase {{package}}, therefore the order is determined by the order
in which the plugins are declared in the plugins section (theoretically). This
is complicated though as profile activation and pom inheritance is taken into
account, for details refer to https://issues.apache.org/jira/browse/MNG-5987
and TBH I don't know which change exactly from
https://github.com/apache/jackrabbit-oak/commit/fcf75771d16f1c89e7c62441ef67f0ad3f37006c#diff-ef85e9003cb1d311055f2c063ab67a54115b8e0e2c1f31638d80e34c075a73bb
can have such an effect (yet)
was (Author: kwin):
The problem is the order of execution: Without profile {{apache-release}} it is
first {{maven-assembly-plugin}} and then {{maven-antrun-plugin}} (for goals
bound to the same phase_, with the profile it is the other way around.
Unfortunately both bind with their executions in
#
https://github.com/apache/jackrabbit-oak/blob/56a0fa0828e42b59089d014a20dff3b378d8edc9/oak-run/pom.xml#L102
and
#
https://github.com/apache/jackrabbit-oak/blob/56a0fa0828e42b59089d014a20dff3b378d8edc9/oak-run/pom.xml#L120
to the same phase {{package}}, therefore the order is determined by the order
in which the plugins are declared in the plugins section (theoretically). This
is complicated though as profile and pom inheritance is taken into account, for
details refer to https://issues.apache.org/jira/browse/MNG-5987 and TBH I don't
know which change exactly from can have such an effect (yet)
> release:perform fails in oak-run
>
>
> Key: OAK-10032
> URL: https://issues.apache.org/jira/browse/OAK-10032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Nitin Gupta
>Priority: Critical
> Fix For: 1.46.0
>
>
> With diagnostics:
> {noformat}
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (default) on project
> oak-run: An Ant BuildException has occured: Warning: Could not find file
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar
> to copy.
> [INFO] [ERROR] around Ant part ... file="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar"
>
> tofile="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0.jar"
> />... @ 4:231 in
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/antrun/build-main.xml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10032) release:perform fails in oak-run
[
https://issues.apache.org/jira/browse/OAK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648228#comment-17648228
]
Konrad Windszus edited comment on OAK-10032 at 12/15/22 8:25 PM:
-
The problem is the order of execution: Without profile {{apache-release}} it is
first {{maven-assembly-plugin}} and then {{maven-antrun-plugin}} (for goals
bound to the same phase_, with the profile it is the other way around.
Unfortunately both bind with their executions in
#
https://github.com/apache/jackrabbit-oak/blob/56a0fa0828e42b59089d014a20dff3b378d8edc9/oak-run/pom.xml#L102
and
#
https://github.com/apache/jackrabbit-oak/blob/56a0fa0828e42b59089d014a20dff3b378d8edc9/oak-run/pom.xml#L120
to the same phase {{package}}, therefore the order is determined by the order
in which the plugins are declared in the plugins section (theoretically). This
is complicated though as profile and pom inheritance is taken into account, for
details refer to https://issues.apache.org/jira/browse/MNG-5987 and TBH I don't
know which change exactly from can have such an effect (yet)
was (Author: kwin):
The problem is the order of execution: Without profile {{apache-release}} it is
first {{maven-assembly-plugin}} and then {{maven-antrun-plugin}}, with the
profile it is the other way around. Unfortunately both bind with their
executions in
#
https://github.com/apache/jackrabbit-oak/blob/56a0fa0828e42b59089d014a20dff3b378d8edc9/oak-run/pom.xml#L102
and
#
https://github.com/apache/jackrabbit-oak/blob/56a0fa0828e42b59089d014a20dff3b378d8edc9/oak-run/pom.xml#L120
to the same phase {{package}}, therefore the order is determined by the order
in which the plugins are declared in the plugins section.
> release:perform fails in oak-run
>
>
> Key: OAK-10032
> URL: https://issues.apache.org/jira/browse/OAK-10032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Nitin Gupta
>Priority: Critical
> Fix For: 1.46.0
>
>
> With diagnostics:
> {noformat}
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (default) on project
> oak-run: An Ant BuildException has occured: Warning: Could not find file
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar
> to copy.
> [INFO] [ERROR] around Ant part ... file="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar"
>
> tofile="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0.jar"
> />... @ 4:231 in
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/antrun/build-main.xml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10032) release:perform fails in oak-run
[
https://issues.apache.org/jira/browse/OAK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648228#comment-17648228
]
Konrad Windszus edited comment on OAK-10032 at 12/15/22 8:04 PM:
-
The problem is the order of execution: Without profile {{apache-release}} it is
first {{maven-assembly-plugin}} and then {{maven-antrun-plugin}}, with the
profile it is the other way around. Unfortunately both bind with their
executions in
#
https://github.com/apache/jackrabbit-oak/blob/56a0fa0828e42b59089d014a20dff3b378d8edc9/oak-run/pom.xml#L102
and
#
https://github.com/apache/jackrabbit-oak/blob/56a0fa0828e42b59089d014a20dff3b378d8edc9/oak-run/pom.xml#L120
to the same phase {{package}}, therefore the order is determined by the order
in which the plugins are declared in the plugins section.
was (Author: kwin):
The problem is the order of execution: Without profile {{apache-release}} it is
first {{maven-assembly-plugin}} and then {{maven-antrun-plugin}}, with the
profile it is the other way around. Unfortunately both bind with their
executions in
#
https://github.com/apache/jackrabbit-oak/blob/56a0fa0828e42b59089d014a20dff3b378d8edc9/oak-run/pom.xml#L102
and
#
https://github.com/apache/jackrabbit-oak/blob/56a0fa0828e42b59089d014a20dff3b378d8edc9/oak-run/pom.xml#L120
to the same phase {{package}}, therefore the order is determined by the order
in which the plugins are listed in the plugins.
> release:perform fails in oak-run
>
>
> Key: OAK-10032
> URL: https://issues.apache.org/jira/browse/OAK-10032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Nitin Gupta
>Priority: Critical
> Fix For: 1.46.0
>
>
> With diagnostics:
> {noformat}
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (default) on project
> oak-run: An Ant BuildException has occured: Warning: Could not find file
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar
> to copy.
> [INFO] [ERROR] around Ant part ... file="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar"
>
> tofile="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0.jar"
> />... @ 4:231 in
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/antrun/build-main.xml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10032) release:perform fails in oak-run
[
https://issues.apache.org/jira/browse/OAK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648228#comment-17648228
]
Konrad Windszus commented on OAK-10032:
---
The problem is the order of execution: Without profile {{apache-release}} it is
first {{maven-assembly-plugin}} and then {{maven-antrun-plugin}}, with the
profile it is the other way around. Unfortunately both bind with their
executions in
#
https://github.com/apache/jackrabbit-oak/blob/56a0fa0828e42b59089d014a20dff3b378d8edc9/oak-run/pom.xml#L102
and
#
https://github.com/apache/jackrabbit-oak/blob/56a0fa0828e42b59089d014a20dff3b378d8edc9/oak-run/pom.xml#L120
to the same phase {{package}}, therefore the order is determined by the order
in which the plugins are listed in the plugins.
> release:perform fails in oak-run
>
>
> Key: OAK-10032
> URL: https://issues.apache.org/jira/browse/OAK-10032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Nitin Gupta
>Priority: Critical
> Fix For: 1.46.0
>
>
> With diagnostics:
> {noformat}
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (default) on project
> oak-run: An Ant BuildException has occured: Warning: Could not find file
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar
> to copy.
> [INFO] [ERROR] around Ant part ... file="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar"
>
> tofile="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0.jar"
> />... @ 4:231 in
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/antrun/build-main.xml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10032) release:perform fails in oak-run
[
https://issues.apache.org/jira/browse/OAK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648143#comment-17648143
]
Konrad Windszus commented on OAK-10032:
---
This is only related to the ant plugin update
> release:perform fails in oak-run
>
>
> Key: OAK-10032
> URL: https://issues.apache.org/jira/browse/OAK-10032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Nitin Gupta
>Priority: Critical
> Fix For: 1.46.0
>
>
> With diagnostics:
> {noformat}
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (default) on project
> oak-run: An Ant BuildException has occured: Warning: Could not find file
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar
> to copy.
> [INFO] [ERROR] around Ant part ... file="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar"
>
> tofile="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0.jar"
> />... @ 4:231 in
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/antrun/build-main.xml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10032) release:perform fails in oak-run
[
https://issues.apache.org/jira/browse/OAK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648142#comment-17648142
]
Konrad Windszus commented on OAK-10032:
---
Give me till tomorrow to investigate
> release:perform fails in oak-run
>
>
> Key: OAK-10032
> URL: https://issues.apache.org/jira/browse/OAK-10032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Nitin Gupta
>Priority: Critical
> Fix For: 1.46.0
>
>
> With diagnostics:
> {noformat}
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (default) on project
> oak-run: An Ant BuildException has occured: Warning: Could not find file
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar
> to copy.
> [INFO] [ERROR] around Ant part ... file="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar"
>
> tofile="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0.jar"
> />... @ 4:231 in
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/antrun/build-main.xml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10032) release:perform fails in oak-run
[
https://issues.apache.org/jira/browse/OAK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648104#comment-17648104
]
Konrad Windszus commented on OAK-10032:
---
There is a Maven profile only active during {{release:perform}} at
https://github.com/apache/jackrabbit-oak/blob/56a0fa0828e42b59089d014a20dff3b378d8edc9/pom.xml#L152.
You can enable that with {{-Papache-release}} also during a regular build.
That one contains the ant script at
https://github.com/apache/jackrabbit-oak/blob/56a0fa0828e42b59089d014a20dff3b378d8edc9/pom.xml#L190-L281.
> release:perform fails in oak-run
>
>
> Key: OAK-10032
> URL: https://issues.apache.org/jira/browse/OAK-10032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Nitin Gupta
>Priority: Critical
> Fix For: 1.46.0
>
>
> With diagnostics:
> {noformat}
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (default) on project
> oak-run: An Ant BuildException has occured: Warning: Could not find file
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar
> to copy.
> [INFO] [ERROR] around Ant part ... file="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar"
>
> tofile="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0.jar"
> />... @ 4:231 in
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/antrun/build-main.xml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10032) release:perform fails in oak-run
[
https://issues.apache.org/jira/browse/OAK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648050#comment-17648050
]
Konrad Windszus edited comment on OAK-10032 at 12/15/22 1:31 PM:
-
Can you share the debug log {{mvn -X}} or at least the full stack trace of the
exception {{mvn -e}}?
-Also please describe when this happened (release:prepare or perform or some
other goal).-
Update: Missed the title.
was (Author: kwin):
Can you share the debug log {{mvn -X}} or at least the full stack trace of the
exception {{mvn -e}}?
Also please describe when this happened (release:prepare or perform or some
other goal).
> release:perform fails in oak-run
>
>
> Key: OAK-10032
> URL: https://issues.apache.org/jira/browse/OAK-10032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Priority: Critical
> Fix For: 1.46.0
>
>
> With diagnostics:
> {noformat}
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (default) on project
> oak-run: An Ant BuildException has occured: Warning: Could not find file
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar
> to copy.
> [INFO] [ERROR] around Ant part ... file="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar"
>
> tofile="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0.jar"
> />... @ 4:231 in
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/antrun/build-main.xml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10032) release:perform fails in oak-run
[
https://issues.apache.org/jira/browse/OAK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648050#comment-17648050
]
Konrad Windszus commented on OAK-10032:
---
Can you share the debug log {{mvn -X}} or at least the full stack trace of the
exception {{mvn -e}}?
Also please describe when this happened (release:prepare or perform or some
other goal).
> release:perform fails in oak-run
>
>
> Key: OAK-10032
> URL: https://issues.apache.org/jira/browse/OAK-10032
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Priority: Critical
> Fix For: 1.46.0
>
>
> With diagnostics:
> {noformat}
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (default) on project
> oak-run: An Ant BuildException has occured: Warning: Could not find file
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar
> to copy.
> [INFO] [ERROR] around Ant part ... file="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0-oak.jar"
>
> tofile="/Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/oak-run-1.46.0.jar"
> />... @ 4:231 in
> /Users/N/jackrabbit_oak_git/jackrabbit-oak/target/checkout/oak-run/target/antrun/build-main.xml
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-9956) javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any unmapped namespaces in expanded path notation
[
https://issues.apache.org/jira/browse/OAK-9956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644424#comment-17644424
]
Konrad Windszus commented on OAK-9956:
--
Improving the exception is good, but to be honest I don't really see how
supporting this can cause regressions as currently all node names with ":" just
lead to an exception in that case while in the future they may succeed. But I
agree that this is an edge case and doesn't necessarily need to be supported.
Still that deviation from the JCR standard should be documented in
https://jackrabbit.apache.org/oak/docs/constraints.html.
> javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any
> unmapped namespaces in expanded path notation
>
>
> Key: OAK-9956
> URL: https://issues.apache.org/jira/browse/OAK-9956
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Assignee: Julian Reschke
>Priority: Major
> Attachments: OAK-9956.diff
>
>
> In case {{Node.addNode(...)}} is called with a path in [expanded
> form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
> containing a namespace URI which is not mapped a
> {{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
> 2.0 spec allows unmapped namespaces according to
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
> and
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
> {quote}When parsing a lexical path, the parser must distinguish between name
> segments that are in expanded form and those that are in qualified form (see
> §3.2.5 Lexical Form of JCR Names). When making this determination, the
> repository cannot assume that every namespace URI encountered in an expanded
> name will be registered within the repository.
> An otherwise valid path containing an expanded name with an unregistered
> namespace URI will always resolve into a valid internal representation of a
> path (i.e., an ordered list of path segments, see §3.4 Paths). Any errors
> that arise from passing such a path must therefore be as a result of further
> processing (not merely parsing) that depends on the semantics of the path and
> the context of use.{quote}
> The same exception is thrown if there is a prefix only locally registered via
> {{Session.setNamespacePrefix()}} for both cases when calling
> {{addNode(...)}} afterwards in either qualified or expanded form.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-9959) RepositoryImpl.shutdown() takes way too long in case of unclosed Sessions
[
https://issues.apache.org/jira/browse/OAK-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-9959:
-
Fix Version/s: 1.46.0
> RepositoryImpl.shutdown() takes way too long in case of unclosed Sessions
> -
>
> Key: OAK-9959
> URL: https://issues.apache.org/jira/browse/OAK-9959
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 1.46.0
>
>
> For ITs I have to spin up new in-memory repositories for individual tests and
> shut them down afterwards. While the startup time is really good, I loose
> almost 5 seconds while calling {{RepositoryImpl.shutdown()}}
> (https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L348)
> during closing the {{scheduledExecutor}}.
> This only happens though when there are unclosed sessions due to this
> executor which is scheduled to run after 1 minute:
> https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L324.
> Would be good though to speed up shutdown even in the case of unclosed
> sessions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-9959) RepositoryImpl.shutdown() takes way too long in case of unclosed Sessions
[
https://issues.apache.org/jira/browse/OAK-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved OAK-9959.
--
Resolution: Fixed
Made the MBean registration optional in
https://github.com/apache/jackrabbit-oak/commit/01a6709f76f65a5118ee18c8f5b194d29d1d60b9.
> RepositoryImpl.shutdown() takes way too long in case of unclosed Sessions
> -
>
> Key: OAK-9959
> URL: https://issues.apache.org/jira/browse/OAK-9959
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> For ITs I have to spin up new in-memory repositories for individual tests and
> shut them down afterwards. While the startup time is really good, I loose
> almost 5 seconds while calling {{RepositoryImpl.shutdown()}}
> (https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L348)
> during closing the {{scheduledExecutor}}.
> This only happens though when there are unclosed sessions due to this
> executor which is scheduled to run after 1 minute:
> https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L324.
> Would be good though to speed up shutdown even in the case of unclosed
> sessions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-9959) RepositoryImpl.shutdown() takes way too long in case of unclosed Sessions
[
https://issues.apache.org/jira/browse/OAK-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610835#comment-17610835
]
Konrad Windszus edited comment on OAK-9959 at 9/29/22 7:52 AM:
---
Maybe the whole Session MBean registration can somehow be made optional, so
that ITs (and maybe other consumers) can opt out of this overhead. This would
implicitly fix this issue as well. As sessions are anyways only exposed as
MBeans if they live longer than 1 minute, for use cases where this is never
the case the overhead should be avoided by explicitly opting out of MBean
registration.
was (Author: kwin):
Maybe the whole Session MBean registration can somehow be made optional, so
that ITs (and maybe other consumers) can opt out of this overhead. This would
implicitly fix this issue as well.
> RepositoryImpl.shutdown() takes way too long in case of unclosed Sessions
> -
>
> Key: OAK-9959
> URL: https://issues.apache.org/jira/browse/OAK-9959
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> For ITs I have to spin up new in-memory repositories for individual tests and
> shut them down afterwards. While the startup time is really good, I loose
> almost 5 seconds while calling {{RepositoryImpl.shutdown()}}
> (https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L348)
> during closing the {{scheduledExecutor}}.
> This only happens though when there are unclosed sessions due to this
> executor which is scheduled to run after 1 minute:
> https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L324.
> Would be good though to speed up shutdown even in the case of unclosed
> sessions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-9959) RepositoryImpl.shutdown() takes way too long in case of unclosed Sessions
[
https://issues.apache.org/jira/browse/OAK-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned OAK-9959:
Assignee: Konrad Windszus
> RepositoryImpl.shutdown() takes way too long in case of unclosed Sessions
> -
>
> Key: OAK-9959
> URL: https://issues.apache.org/jira/browse/OAK-9959
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> For ITs I have to spin up new in-memory repositories for individual tests and
> shut them down afterwards. While the startup time is really good, I loose
> almost 5 seconds while calling {{RepositoryImpl.shutdown()}}
> (https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L348)
> during closing the {{scheduledExecutor}}.
> This only happens though when there are unclosed sessions due to this
> executor which is scheduled to run after 1 minute:
> https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L324.
> Would be good though to speed up shutdown even in the case of unclosed
> sessions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-9959) RepositoryImpl.shutdown() takes way too long in case of unclosed Sessions
[
https://issues.apache.org/jira/browse/OAK-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610835#comment-17610835
]
Konrad Windszus commented on OAK-9959:
--
Maybe the whole Session MBean registration can somehow be made optional, so
that ITs (and maybe other consumers) can opt out of this overhead. This would
implicitly fix this issue as well.
> RepositoryImpl.shutdown() takes way too long in case of unclosed Sessions
> -
>
> Key: OAK-9959
> URL: https://issues.apache.org/jira/browse/OAK-9959
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Priority: Major
>
> For ITs I have to spin up new in-memory repositories for individual tests and
> shut them down afterwards. While the startup time is really good, I loose
> almost 5 seconds while calling {{RepositoryImpl.shutdown()}}
> (https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L348)
> during closing the {{scheduledExecutor}}.
> This only happens though when there are unclosed sessions due to this
> executor which is scheduled to run after 1 minute:
> https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L324.
> Would be good though to speed up shutdown even in the case of unclosed
> sessions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-9959) RepositoryImpl.shutdown() takes way too long in case of unclosed Sessions
[
https://issues.apache.org/jira/browse/OAK-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-9959:
-
Summary: RepositoryImpl.shutdown() takes way too long in case of unclosed
Sessions (was: RepositoryImpl.shutdown() takes way too long)
> RepositoryImpl.shutdown() takes way too long in case of unclosed Sessions
> -
>
> Key: OAK-9959
> URL: https://issues.apache.org/jira/browse/OAK-9959
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Priority: Major
>
> For ITs I have to spin up new in-memory repositories for individual tests and
> shut them down afterwards. While the startup time is really good, I loose
> almost 5 seconds while calling {{RepositoryImpl.shutdown()}}
> (https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L348)
> during closing the {{scheduledExecutor}}.
> This only happens though when there are unclosed sessions due to this
> executor which is scheduled to run after 1 minute:
> https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L324.
> Would be good though to speed up shutdown even in the case of unclosed
> sessions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-9959) RepositoryImpl.shutdown() takes way too long
[
https://issues.apache.org/jira/browse/OAK-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-9959:
-
Description:
For ITs I have to spin up new in-memory repositories for individual tests and
shut them down afterwards. While the startup time is really good, I loose
almost 5 seconds while calling {{RepositoryImpl.shutdown()}}
(https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L348)
during closing the {{scheduledExecutor}}.
This only happens though when there are unclosed sessions due to this executor
which is scheduled to run after 1 minute:
https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L324.
Would be good though to speed up shutdown even in the case of unclosed sessions.
was:For ITs I have to spin up new in-memory repositories for individual tests
and shut them down afterwards. While the startup time is really good, I loose
almost 5 seconds while calling {{RepositoryImpl.shutdown()}}
(https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L348)
during closing the {{scheduledExecutor}}.
> RepositoryImpl.shutdown() takes way too long
>
>
> Key: OAK-9959
> URL: https://issues.apache.org/jira/browse/OAK-9959
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Priority: Major
>
> For ITs I have to spin up new in-memory repositories for individual tests and
> shut them down afterwards. While the startup time is really good, I loose
> almost 5 seconds while calling {{RepositoryImpl.shutdown()}}
> (https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L348)
> during closing the {{scheduledExecutor}}.
> This only happens though when there are unclosed sessions due to this
> executor which is scheduled to run after 1 minute:
> https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L324.
> Would be good though to speed up shutdown even in the case of unclosed
> sessions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-9959) RepositoryImpl.shutdown() takes way too long
Konrad Windszus created OAK-9959:
Summary: RepositoryImpl.shutdown() takes way too long
Key: OAK-9959
URL: https://issues.apache.org/jira/browse/OAK-9959
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Affects Versions: 1.44.0
Reporter: Konrad Windszus
For ITs I have to spin up new in-memory repositories for individual tests and
shut them down afterwards. While the startup time is really good, I loose
almost 5 seconds while calling {{RepositoryImpl.shutdown()}}
(https://github.com/apache/jackrabbit-oak/blob/cde907088a5c460178fd714cb4edc141cd45e23d/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/repository/RepositoryImpl.java#L348)
during closing the {{scheduledExecutor}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-9956) javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any unmapped namespaces in expanded path notation
[
https://issues.apache.org/jira/browse/OAK-9956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17609473#comment-17609473
]
Konrad Windszus commented on OAK-9956:
--
bq. So that is actually correct behavior.
IMHO not, according to JCR spec it should be supported to use unmapped
namespaces (both with nodes and properties).
> javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any
> unmapped namespaces in expanded path notation
>
>
> Key: OAK-9956
> URL: https://issues.apache.org/jira/browse/OAK-9956
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Priority: Major
>
> In case {{Node.addNode(...)}} is called with a path in [expanded
> form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
> containing a namespace URI which is not mapped a
> {{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
> 2.0 spec allows unmapped namespaces according to
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
> and
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
> {quote}When parsing a lexical path, the parser must distinguish between name
> segments that are in expanded form and those that are in qualified form (see
> §3.2.5 Lexical Form of JCR Names). When making this determination, the
> repository cannot assume that every namespace URI encountered in an expanded
> name will be registered within the repository.
> An otherwise valid path containing an expanded name with an unregistered
> namespace URI will always resolve into a valid internal representation of a
> path (i.e., an ordered list of path segments, see §3.4 Paths). Any errors
> that arise from passing such a path must therefore be as a result of further
> processing (not merely parsing) that depends on the semantics of the path and
> the context of use.{quote}
> The same exception is thrown if there is a prefix only locally registered via
> {{Session.setNamespacePrefix()}} for both cases when calling
> {{addNode(...)}} afterwards in either qualified or expanded form.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-9956) javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any unmapped namespaces in expanded path notation
[
https://issues.apache.org/jira/browse/OAK-9956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17609455#comment-17609455
]
Konrad Windszus edited comment on OAK-9956 at 9/26/22 11:58 AM:
bq. FWIW, "setProperty()" has a similar problem; it just persists the expanded
form literally.
This is just the case if an invalid namespace URI (without a colon) is given,
as then you actually deal with a qualified name without a namespace, compare
with
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.3%20Qualified%20Form%20with%20the%20Empty%20Namespace.
When calling {{node.setProperty("\{my:Namespace}foo", "bar");}} you run into a
{{javax.jcr.RepositoryException: Invalid name or path: \{my:Namespace\}foo}}
was (Author: kwin):
> FWIW, "setProperty()" has a similar problem; it just persists the expanded
> form literally.
This is just the case if an invalid namespace URI (without a colon) is given,
as then you actually deal with a qualified name without a namespace, compare
with
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.3%20Qualified%20Form%20with%20the%20Empty%20Namespace.
When calling {{node.setProperty("\{my:Namespace}foo", "bar");}} you run into a
{{javax.jcr.RepositoryException: Invalid name or path: \{my:Namespace}foo}}
> javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any
> unmapped namespaces in expanded path notation
>
>
> Key: OAK-9956
> URL: https://issues.apache.org/jira/browse/OAK-9956
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Priority: Major
>
> In case {{Node.addNode(...)}} is called with a path in [expanded
> form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
> containing a namespace URI which is not mapped a
> {{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
> 2.0 spec allows unmapped namespaces according to
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
> and
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
> {quote}When parsing a lexical path, the parser must distinguish between name
> segments that are in expanded form and those that are in qualified form (see
> §3.2.5 Lexical Form of JCR Names). When making this determination, the
> repository cannot assume that every namespace URI encountered in an expanded
> name will be registered within the repository.
> An otherwise valid path containing an expanded name with an unregistered
> namespace URI will always resolve into a valid internal representation of a
> path (i.e., an ordered list of path segments, see §3.4 Paths). Any errors
> that arise from passing such a path must therefore be as a result of further
> processing (not merely parsing) that depends on the semantics of the path and
> the context of use.{quote}
> The same exception is thrown if there is a prefix only locally registered via
> {{Session.setNamespacePrefix()}} for both cases when calling
> {{addNode(...)}} afterwards in either qualified or expanded form.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-9956) javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any unmapped namespaces in expanded path notation
[
https://issues.apache.org/jira/browse/OAK-9956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17609455#comment-17609455
]
Konrad Windszus edited comment on OAK-9956 at 9/26/22 11:57 AM:
{quote} FWIW, "setProperty()" has a similar problem; it just persists the
expanded form literally{quote}
This is just the case if an invalid namespace URI (without a colon) is given,
as then you actually deal with a qualified name without a namespace, compare
with
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.3%20Qualified%20Form%20with%20the%20Empty%20Namespace.
When calling
{code}node.setProperty("{my:Namespace}foo", "bar"){code}
you run into a
{code}javax.jcr.RepositoryException: Invalid name or path:
{my:Namespace}foo}{code}
was (Author: kwin):
> FWIW, "setProperty()" has a similar problem; it just persists the expanded
> form literally.
This is just the case if an invalid namespace URI (without a colon) is given,
as then you actually deal with a qualified name without a namespace, compare
with
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.3%20Qualified%20Form%20with%20the%20Empty%20Namespace.
When calling {{node.setProperty("{my:Namespace}foo", "bar");}} you run into a
{{javax.jcr.RepositoryException: Invalid name or path: {my:Namespace}foo}}
> javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any
> unmapped namespaces in expanded path notation
>
>
> Key: OAK-9956
> URL: https://issues.apache.org/jira/browse/OAK-9956
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Priority: Major
>
> In case {{Node.addNode(...)}} is called with a path in [expanded
> form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
> containing a namespace URI which is not mapped a
> {{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
> 2.0 spec allows unmapped namespaces according to
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
> and
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
> {quote}When parsing a lexical path, the parser must distinguish between name
> segments that are in expanded form and those that are in qualified form (see
> §3.2.5 Lexical Form of JCR Names). When making this determination, the
> repository cannot assume that every namespace URI encountered in an expanded
> name will be registered within the repository.
> An otherwise valid path containing an expanded name with an unregistered
> namespace URI will always resolve into a valid internal representation of a
> path (i.e., an ordered list of path segments, see §3.4 Paths). Any errors
> that arise from passing such a path must therefore be as a result of further
> processing (not merely parsing) that depends on the semantics of the path and
> the context of use.{quote}
> The same exception is thrown if there is a prefix only locally registered via
> {{Session.setNamespacePrefix()}} for both cases when calling
> {{addNode(...)}} afterwards in either qualified or expanded form.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-9956) javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any unmapped namespaces in expanded path notation
[
https://issues.apache.org/jira/browse/OAK-9956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17609455#comment-17609455
]
Konrad Windszus commented on OAK-9956:
--
> FWIW, "setProperty()" has a similar problem; it just persists the expanded
> form literally.
This is just the case if an invalid namespace URI (without a colon) is given,
as then you actually deal with a qualified name without a namespace, compare
with
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.3%20Qualified%20Form%20with%20the%20Empty%20Namespace.
When calling {{node.setProperty("{my:Namespace}foo", "bar");}} you run into a
{{javax.jcr.RepositoryException: Invalid name or path: {my:Namespace}foo}}
> javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any
> unmapped namespaces in expanded path notation
>
>
> Key: OAK-9956
> URL: https://issues.apache.org/jira/browse/OAK-9956
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Priority: Major
>
> In case {{Node.addNode(...)}} is called with a path in [expanded
> form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
> containing a namespace URI which is not mapped a
> {{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
> 2.0 spec allows unmapped namespaces according to
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
> and
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
> {quote}When parsing a lexical path, the parser must distinguish between name
> segments that are in expanded form and those that are in qualified form (see
> §3.2.5 Lexical Form of JCR Names). When making this determination, the
> repository cannot assume that every namespace URI encountered in an expanded
> name will be registered within the repository.
> An otherwise valid path containing an expanded name with an unregistered
> namespace URI will always resolve into a valid internal representation of a
> path (i.e., an ordered list of path segments, see §3.4 Paths). Any errors
> that arise from passing such a path must therefore be as a result of further
> processing (not merely parsing) that depends on the semantics of the path and
> the context of use.{quote}
> The same exception is thrown if there is a prefix only locally registered via
> {{Session.setNamespacePrefix()}} for both cases when calling
> {{addNode(...)}} afterwards in either qualified or expanded form.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-9956) javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any unmapped namespaces in expanded path notation
[
https://issues.apache.org/jira/browse/OAK-9956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17609135#comment-17609135
]
Konrad Windszus commented on OAK-9956:
--
Seems that both Oak and JR2 violate
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2.1%20Effect%20of%20Session%20Namespace%20Mappings:
{quote}Though the precise mechanism of this behavior is an implementation
detail, its behavior must be equivalent to that of a system where names and
paths are stored internally in expanded form and converted dynamically to and
from qualified JCR names or paths as necessary.{quote}
IIUC both Oak and JR2 store internally paths in qualified form, which makes
them behave like this.
> javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any
> unmapped namespaces in expanded path notation
>
>
> Key: OAK-9956
> URL: https://issues.apache.org/jira/browse/OAK-9956
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Priority: Major
>
> In case {{Node.addNode(...)}} is called with a path in [expanded
> form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
> containing a namespace URI which is not mapped a
> {{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
> 2.0 spec allows unmapped namespaces according to
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
> and
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
> {quote}When parsing a lexical path, the parser must distinguish between name
> segments that are in expanded form and those that are in qualified form (see
> §3.2.5 Lexical Form of JCR Names). When making this determination, the
> repository cannot assume that every namespace URI encountered in an expanded
> name will be registered within the repository.
> An otherwise valid path containing an expanded name with an unregistered
> namespace URI will always resolve into a valid internal representation of a
> path (i.e., an ordered list of path segments, see §3.4 Paths). Any errors
> that arise from passing such a path must therefore be as a result of further
> processing (not merely parsing) that depends on the semantics of the path and
> the context of use.{quote}
> The same exception is thrown if there is a prefix only locally registered via
> {{Session.setNamespacePrefix()}} for both cases when calling
> {{addNode(...)}} afterwards in either qualified or expanded form.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-9956) javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any unmapped namespaces in expanded path notation
[
https://issues.apache.org/jira/browse/OAK-9956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17609134#comment-17609134
]
Konrad Windszus commented on OAK-9956:
--
JR2 throws the generic {{javax.jcr.RepositoryException}} for those cases, so
also JR2 seems to be not JCR 2.0 compliant.
> javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any
> unmapped namespaces in expanded path notation
>
>
> Key: OAK-9956
> URL: https://issues.apache.org/jira/browse/OAK-9956
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Priority: Major
>
> In case {{Node.addNode(...)}} is called with a path in [expanded
> form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
> containing a namespace URI which is not mapped a
> {{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
> 2.0 spec allows unmapped namespaces according to
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
> and
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
> {quote}When parsing a lexical path, the parser must distinguish between name
> segments that are in expanded form and those that are in qualified form (see
> §3.2.5 Lexical Form of JCR Names). When making this determination, the
> repository cannot assume that every namespace URI encountered in an expanded
> name will be registered within the repository.
> An otherwise valid path containing an expanded name with an unregistered
> namespace URI will always resolve into a valid internal representation of a
> path (i.e., an ordered list of path segments, see §3.4 Paths). Any errors
> that arise from passing such a path must therefore be as a result of further
> processing (not merely parsing) that depends on the semantics of the path and
> the context of use.{quote}
> The same exception is thrown if there is a prefix only locally registered via
> {{Session.setNamespacePrefix()}} for both cases when calling
> {{addNode(...)}} afterwards in either qualified or expanded form.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-9956) javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any unmapped namespaces in expanded path notation
[
https://issues.apache.org/jira/browse/OAK-9956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-9956:
-
Description:
In case {{Node.addNode(...)}} is called with a path in [expanded
form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
containing a namespace URI which is not mapped a
{{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
2.0 spec allows unmapped namespaces according to
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
and
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
{quote}When parsing a lexical path, the parser must distinguish between name
segments that are in expanded form and those that are in qualified form (see
§3.2.5 Lexical Form of JCR Names). When making this determination, the
repository cannot assume that every namespace URI encountered in an expanded
name will be registered within the repository.
An otherwise valid path containing an expanded name with an unregistered
namespace URI will always resolve into a valid internal representation of a
path (i.e., an ordered list of path segments, see §3.4 Paths). Any errors that
arise from passing such a path must therefore be as a result of further
processing (not merely parsing) that depends on the semantics of the path and
the context of use.{quote}
The same exception is thrown if there is a prefix only locally registered via
{{Session.setNamespacePrefix()}} for both cases when calling
{{addNode(...)}} afterwards in either qualified or expanded form.
was:
In case {{Session.addNode(...)}} is called with a path in [expanded
form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
containing a namespace URI which is not mapped a
{{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
2.0 spec allows unmapped namespaces according to
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
and
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
{quote}When parsing a lexical path, the parser must distinguish between name
segments that are in expanded form and those that are in qualified form (see
§3.2.5 Lexical Form of JCR Names). When making this determination, the
repository cannot assume that every namespace URI encountered in an expanded
name will be registered within the repository.
An otherwise valid path containing an expanded name with an unregistered
namespace URI will always resolve into a valid internal representation of a
path (i.e., an ordered list of path segments, see §3.4 Paths). Any errors that
arise from passing such a path must therefore be as a result of further
processing (not merely parsing) that depends on the semantics of the path and
the context of use.{quote}
The same exception is thrown if there is a prefix only locally registered via
{{Session.setNamespacePrefix()}} for both cases when calling
{{addNode(...)}} afterwards in either qualified or expanded form.
> javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any
> unmapped namespaces in expanded path notation
>
>
> Key: OAK-9956
> URL: https://issues.apache.org/jira/browse/OAK-9956
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Priority: Major
>
> In case {{Node.addNode(...)}} is called with a path in [expanded
> form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
> containing a namespace URI which is not mapped a
> {{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
> 2.0 spec allows unmapped namespaces according to
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
> and
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
> {quote}When parsing a lexical path, the parser must distinguish between name
> segments that are in expanded form and those that are in qualified form (see
> §3.2.5 Lexical Form of JCR Names). When making this determination, the
> repository cannot assume that every namespace URI
[jira] [Updated] (OAK-9956) javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any unmapped namespaces in expanded path notation
[
https://issues.apache.org/jira/browse/OAK-9956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-9956:
-
Summary: javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException
for any unmapped namespaces in expanded path notation (was:
javax.jcr.Session.addNode(...) throws javax.jcr.PathNotFoundException for any
unmapped namespaces in expanded path notation)
> javax.jcr.Node.addNode(...) throws javax.jcr.PathNotFoundException for any
> unmapped namespaces in expanded path notation
>
>
> Key: OAK-9956
> URL: https://issues.apache.org/jira/browse/OAK-9956
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Priority: Major
>
> In case {{Session.addNode(...)}} is called with a path in [expanded
> form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
> containing a namespace URI which is not mapped a
> {{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
> 2.0 spec allows unmapped namespaces according to
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
> and
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
> {quote}When parsing a lexical path, the parser must distinguish between name
> segments that are in expanded form and those that are in qualified form (see
> §3.2.5 Lexical Form of JCR Names). When making this determination, the
> repository cannot assume that every namespace URI encountered in an expanded
> name will be registered within the repository.
> An otherwise valid path containing an expanded name with an unregistered
> namespace URI will always resolve into a valid internal representation of a
> path (i.e., an ordered list of path segments, see §3.4 Paths). Any errors
> that arise from passing such a path must therefore be as a result of further
> processing (not merely parsing) that depends on the semantics of the path and
> the context of use.{quote}
> The same exception is thrown if there is a prefix only locally registered via
> {{Session.setNamespacePrefix()}} for both cases when calling
> {{addNode(...)}} afterwards in either qualified or expanded form.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-9956) javax.jcr.Session.addNode(...) throws javax.jcr.PathNotFoundException for any unmapped namespaces in expanded path notation
[
https://issues.apache.org/jira/browse/OAK-9956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-9956:
-
Description:
In case {{Session.addNode(...)}} is called with a path in [expanded
form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
containing a namespace URI which is not mapped a
{{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
2.0 spec allows unmapped namespaces according to
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
and
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
{quote}When parsing a lexical path, the parser must distinguish between name
segments that are in expanded form and those that are in qualified form (see
§3.2.5 Lexical Form of JCR Names). When making this determination, the
repository cannot assume that every namespace URI encountered in an expanded
name will be registered within the repository.
An otherwise valid path containing an expanded name with an unregistered
namespace URI will always resolve into a valid internal representation of a
path (i.e., an ordered list of path segments, see §3.4 Paths). Any errors that
arise from passing such a path must therefore be as a result of further
processing (not merely parsing) that depends on the semantics of the path and
the context of use.{quote}
The same exception is thrown if there is a prefix only locally registered via
{{Session.setNamespacePrefix()}} for both cases when calling
{{addNode(...)}} afterwards in either qualified or expanded form.
was:
In case {{Session.addNode(...)}} is called with a path in [expanded
form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
containing a namespace URI which is not mapped a
{{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
2.0 spec allows unmapped namespaces according to
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
and
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
{quote}When parsing a lexical path, the parser must distinguish between name
segments that are in expanded form and those that are in qualified form (see
§3.2.5 Lexical Form of JCR Names). When making this determination, the
repository cannot assume that every namespace URI encountered in an expanded
name will be registered within the repository.
An otherwise valid path containing an expanded name with an unregistered
namespace URI will always resolve into a valid internal representation of a
path (i.e., an ordered list of path segments, see §3.4 Paths). Any errors that
arise from passing such a path must therefore be as a result of further
processing (not merely parsing) that depends on the semantics of the path and
the context of use.{quote}
The same exception is thrown if there is a prefix only locally registered via
{{Session.setNamespacePrefix()}}
> javax.jcr.Session.addNode(...) throws javax.jcr.PathNotFoundException for any
> unmapped namespaces in expanded path notation
> ---
>
> Key: OAK-9956
> URL: https://issues.apache.org/jira/browse/OAK-9956
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Priority: Major
>
> In case {{Session.addNode(...)}} is called with a path in [expanded
> form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
> containing a namespace URI which is not mapped a
> {{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
> 2.0 spec allows unmapped namespaces according to
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
> and
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
> {quote}When parsing a lexical path, the parser must distinguish between name
> segments that are in expanded form and those that are in qualified form (see
> §3.2.5 Lexical Form of JCR Names). When making this determination, the
> repository cannot assume that every namespace URI encountered in an expanded
> name will be registered within the repository.
> An
[jira] [Updated] (OAK-9956) javax.jcr.Session.addNode(...) throws javax.jcr.PathNotFoundException for any unmapped namespaces in expanded path notation
[
https://issues.apache.org/jira/browse/OAK-9956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-9956:
-
Description:
In case {{Session.addNode(...)}} is called with a path in [expanded
form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
containing a namespace URI which is not mapped a
{{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
2.0 spec allows unmapped namespaces according to
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
and
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
{quote}When parsing a lexical path, the parser must distinguish between name
segments that are in expanded form and those that are in qualified form (see
§3.2.5 Lexical Form of JCR Names). When making this determination, the
repository cannot assume that every namespace URI encountered in an expanded
name will be registered within the repository.
An otherwise valid path containing an expanded name with an unregistered
namespace URI will always resolve into a valid internal representation of a
path (i.e., an ordered list of path segments, see §3.4 Paths). Any errors that
arise from passing such a path must therefore be as a result of further
processing (not merely parsing) that depends on the semantics of the path and
the context of use.{quote}
The same exception is thrown if there is a prefix only locally registered via
{{Session.setNamespacePrefix()}}
was:
In case {{Session.addNode(...)}} is called with a path in [expanded
form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
containing a namespace URI which is not mapped a
{{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
2.0 spec allows unmapped namespaces according to
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
and
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
{quote}When parsing a lexical path, the parser must distinguish between name
segments that are in expanded form and those that are in qualified form (see
§3.2.5 Lexical Form of JCR Names). When making this determination, the
repository cannot assume that every namespace URI encountered in an expanded
name will be registered within the repository.
An otherwise valid path containing an expanded name with an unregistered
namespace URI will always resolve into a valid internal representation of a
path (i.e., an ordered list of path segments, see §3.4 Paths). Any errors that
arise from passing such a path must therefore be as a result of further
processing (not merely parsing) that depends on the semantics of the path and
the context of use.{quote}
> javax.jcr.Session.addNode(...) throws javax.jcr.PathNotFoundException for any
> unmapped namespaces in expanded path notation
> ---
>
> Key: OAK-9956
> URL: https://issues.apache.org/jira/browse/OAK-9956
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Priority: Major
>
> In case {{Session.addNode(...)}} is called with a path in [expanded
> form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
> containing a namespace URI which is not mapped a
> {{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
> 2.0 spec allows unmapped namespaces according to
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
> and
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
> {quote}When parsing a lexical path, the parser must distinguish between name
> segments that are in expanded form and those that are in qualified form (see
> §3.2.5 Lexical Form of JCR Names). When making this determination, the
> repository cannot assume that every namespace URI encountered in an expanded
> name will be registered within the repository.
> An otherwise valid path containing an expanded name with an unregistered
> namespace URI will always resolve into a valid internal representation of a
> path (i.e., an ordered list of path segments, see §3.4 Paths). Any
[jira] [Updated] (OAK-9956) javax.jcr.Session.addNode(...) throws javax.jcr.PathNotFoundException for any unmapped namespaces in expanded path notation
[
https://issues.apache.org/jira/browse/OAK-9956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-9956:
-
Description:
In case {{Session.addNode(...)}} is called with a path in [expanded
form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
containing a namespace URI which is not mapped a
{{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
2.0 spec allows unmapped namespaces according to
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
and
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
{quote}When parsing a lexical path, the parser must distinguish between name
segments that are in expanded form and those that are in qualified form (see
§3.2.5 Lexical Form of JCR Names). When making this determination, the
repository cannot assume that every namespace URI encountered in an expanded
name will be registered within the repository.
An otherwise valid path containing an expanded name with an unregistered
namespace URI will always resolve into a valid internal representation of a
path (i.e., an ordered list of path segments, see §3.4 Paths). Any errors that
arise from passing such a path must therefore be as a result of further
processing (not merely parsing) that depends on the semantics of the path and
the context of use.{quote}
was:In case {{Session.addNode(...)}} is called with a path in [expanded
form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
containing a namespace URI which is not mapped a
{{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
2.0 spec allows unmapped namespaces according to
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
> javax.jcr.Session.addNode(...) throws javax.jcr.PathNotFoundException for any
> unmapped namespaces in expanded path notation
> ---
>
> Key: OAK-9956
> URL: https://issues.apache.org/jira/browse/OAK-9956
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Priority: Major
>
> In case {{Session.addNode(...)}} is called with a path in [expanded
> form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
> containing a namespace URI which is not mapped a
> {{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
> 2.0 spec allows unmapped namespaces according to
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
> and
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.4.3.4%20Parsing%20Lexical%20Paths
> {quote}When parsing a lexical path, the parser must distinguish between name
> segments that are in expanded form and those that are in qualified form (see
> §3.2.5 Lexical Form of JCR Names). When making this determination, the
> repository cannot assume that every namespace URI encountered in an expanded
> name will be registered within the repository.
> An otherwise valid path containing an expanded name with an unregistered
> namespace URI will always resolve into a valid internal representation of a
> path (i.e., an ordered list of path segments, see §3.4 Paths). Any errors
> that arise from passing such a path must therefore be as a result of further
> processing (not merely parsing) that depends on the semantics of the path and
> the context of use.{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-9956) javax.jcr.Session.addNode(...) throws javax.jcr.PathNotFoundException for any unmapped namespaces in expanded path notation
[
https://issues.apache.org/jira/browse/OAK-9956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated OAK-9956:
-
Description: In case {{Session.addNode(...)}} is called with a path in
[expanded
form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
containing a namespace URI which is not mapped a
{{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
2.0 spec allows unmapped namespaces according to
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
(was: In case {{addNode(...)}} is called with a path in [expanded
form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
containing a namespace URI which is not mapped a
{{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
2.0 spec allows unmapped namespaces according to
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings)
> javax.jcr.Session.addNode(...) throws javax.jcr.PathNotFoundException for any
> unmapped namespaces in expanded path notation
> ---
>
> Key: OAK-9956
> URL: https://issues.apache.org/jira/browse/OAK-9956
> Project: Jackrabbit Oak
> Issue Type: Bug
>Affects Versions: 1.44.0
>Reporter: Konrad Windszus
>Priority: Major
>
> In case {{Session.addNode(...)}} is called with a path in [expanded
> form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
> containing a namespace URI which is not mapped a
> {{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
> 2.0 spec allows unmapped namespaces according to
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-9956) javax.jcr.Session.addNode(...) throws javax.jcr.PathNotFoundException for any unmapped namespaces in expanded path notation
Konrad Windszus created OAK-9956:
Summary: javax.jcr.Session.addNode(...) throws
javax.jcr.PathNotFoundException for any unmapped namespaces in expanded path
notation
Key: OAK-9956
URL: https://issues.apache.org/jira/browse/OAK-9956
Project: Jackrabbit Oak
Issue Type: Bug
Affects Versions: 1.44.0
Reporter: Konrad Windszus
In case {{addNode(...)}} is called with a path in [expanded
form|https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form]
containing a namespace URI which is not mapped a
{{javax.jcr.PathNotFoundException}} is thrown. This is unexpected as the JCR
2.0 spec allows unmapped namespaces according to
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.5.2%20Session-Local%20Mappings
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
