[jira] [Updated] (SLING-11621) Outdated JCR dependencies
[
https://issues.apache.org/jira/browse/SLING-11621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-11621:
---
Fix Version/s: (was: Repoinit JCR 1.1.50)
> Outdated JCR dependencies
> -
>
> Key: SLING-11621
> URL: https://issues.apache.org/jira/browse/SLING-11621
> Project: Sling
> Issue Type: Task
> Components: Repoinit
>Reporter: Julian Reschke
>Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> https://github.com/apache/sling-org-apache-sling-jcr-repoinit/blob/9913b787574186a7a31d184480cec3862816438f/pom.xml#L39:
> {noformat}
> 2.18.2
> 1.22.1
> {noformat}
> Jackrabbit 2.18 has been EOLd quite some time ago...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12122) Add unit-test creating group with rep:externalId property
[
https://issues.apache.org/jira/browse/SLING-12122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-12122:
---
Fix Version/s: (was: Repoinit JCR 1.1.50)
> Add unit-test creating group with rep:externalId property
> -
>
> Key: SLING-12122
> URL: https://issues.apache.org/jira/browse/SLING-12122
> Project: Sling
> Issue Type: Test
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
>
> Add a unit-test validating that repoinit can successfully create a new group
> with the {{rep:externalId}} property, that can only be set on creation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12329) Backwards compatibility for legacy repoinit statement reordering
[ https://issues.apache.org/jira/browse/SLING-12329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding resolved SLING-12329. Resolution: Fixed > Backwards compatibility for legacy repoinit statement reordering > > > Key: SLING-12329 > URL: https://issues.apache.org/jira/browse/SLING-12329 > Project: Sling > Issue Type: Improvement > Components: Repoinit >Affects Versions: Repoinit JCR 1.1.46 >Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > Fix For: Repoinit JCR 1.1.50 > > > The fix for repoinit statement reordering can cause issues for users relying > on the legacy ordering. > We should support a fallback to the legacy ordering and log a deprecation > message, warning users that their repoinit script relies on the legacy > ordering, support for which may be removed in the future. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12237) Extend exception message for RepositoryInitializerFactory with config PID and affected script/reference
[
https://issues.apache.org/jira/browse/SLING-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding closed SLING-12237.
--
> Extend exception message for RepositoryInitializerFactory with config PID and
> affected script/reference
> ---
>
> Key: SLING-12237
> URL: https://issues.apache.org/jira/browse/SLING-12237
> Project: Sling
> Issue Type: Improvement
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Repoinit JCR 1.1.48
>
>
> Currently an error in any of the repoinit scripts or reference just lead to
> an exception which does not expose the configuration PID triggering the
> exception, e.g.
> {code}
> javax.jcr.RepositoryException: Applying repoinit operation failed despite
> retry; set loglevel to DEBUG to see all exceptions. Last exception message
> was: Session.save failed: javax.jcr.nodetype.ConstraintViolationException:
> OakConstraint0001: /var/groovyconsole[[nt:folder]]: No matching definition
> found for child node audit with effective type [nt:unstructured]
> at
> org.apache.sling.jcr.repoinit.impl.RepositoryInitializerFactory.applyOperations(RepositoryInitializerFactory.java:176)
> [org.apache.sling.jcr.repoinit:1.1.38]
> {code}
> As repo init scripts are contributed from many different source locations the
> underlying configuration PID should be contained in the exception message as
> well. In addition the index of the according script or the according
> reference URL should be included.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12323) [RepoInit] Avoid java.nio.file.Path for parsing repository paths
[
https://issues.apache.org/jira/browse/SLING-12323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding closed SLING-12323.
--
> [RepoInit] Avoid java.nio.file.Path for parsing repository paths
>
>
> Key: SLING-12323
> URL: https://issues.apache.org/jira/browse/SLING-12323
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: Repoinit JCR 1.1.48
>
>
> RepoInit uses {{java.nio.file.Path}} to determine the "parent path" and
> "name" of a relative repository path. This fails on Windows when the relative
> repository path contains a colon ":".
> The implementation should not be platform dependent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12243) Standalone execution of Repoinit statements is not clearly documented
[ https://issues.apache.org/jira/browse/SLING-12243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-12243. -- > Standalone execution of Repoinit statements is not clearly documented > - > > Key: SLING-12243 > URL: https://issues.apache.org/jira/browse/SLING-12243 > Project: Sling > Issue Type: Bug > Components: Repoinit >Affects Versions: Repoinit JCR 1.1.46 >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > Fix For: Repoinit JCR 1.1.48 > > > The repoinit documentation at > [https://sling.apache.org/documentation/bundles/repository-initialization.html] > does not clearly indicate how to execute repoinit statements outside of the > repository initialization cycle. The information is present but not obvious. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12329) Backwards compatibility for legacy repoinit statement reordering
Julian Sedding created SLING-12329: -- Summary: Backwards compatibility for legacy repoinit statement reordering Key: SLING-12329 URL: https://issues.apache.org/jira/browse/SLING-12329 Project: Sling Issue Type: Improvement Components: Repoinit Affects Versions: Repoinit JCR 1.1.46 Reporter: Julian Sedding Assignee: Julian Sedding Fix For: Repoinit JCR 1.1.50 The fix for repoinit statement reordering can cause issues for users relying on the legacy ordering. We should support a fallback to the legacy ordering and log a deprecation message, warning users that their repoinit script relies on the legacy ordering, support for which may be removed in the future. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12323) [RepoInit] Avoid java.nio.file.Path for parsing repository paths
[
https://issues.apache.org/jira/browse/SLING-12323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding resolved SLING-12323.
Fix Version/s: Repoinit JCR 1.1.48
Resolution: Fixed
> [RepoInit] Avoid java.nio.file.Path for parsing repository paths
>
>
> Key: SLING-12323
> URL: https://issues.apache.org/jira/browse/SLING-12323
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: Repoinit JCR 1.1.48
>
>
> RepoInit uses {{java.nio.file.Path}} to determine the "parent path" and
> "name" of a relative repository path. This fails on Windows when the relative
> repository path contains a colon ":".
> The implementation should not be platform dependent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12323) [RepoInit] Avoid java.nio.file.Path for parsing repository paths
Julian Sedding created SLING-12323:
--
Summary: [RepoInit] Avoid java.nio.file.Path for parsing
repository paths
Key: SLING-12323
URL: https://issues.apache.org/jira/browse/SLING-12323
Project: Sling
Issue Type: Bug
Components: Repoinit
Affects Versions: Repoinit JCR 1.1.46
Reporter: Julian Sedding
Assignee: Julian Sedding
RepoInit uses {{java.nio.file.Path}} to determine the "parent path" and "name"
of a relative repository path. This fails on Windows when the relative
repository path contains a colon ":".
The implementation should not be platform dependent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12162) Update o.a.s.junit.core to jupiter 5.10.1
[ https://issues.apache.org/jira/browse/SLING-12162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding resolved SLING-12162. Resolution: Fixed > Update o.a.s.junit.core to jupiter 5.10.1 > - > > Key: SLING-12162 > URL: https://issues.apache.org/jira/browse/SLING-12162 > Project: Sling > Issue Type: Task > Components: JUnit Core >Affects Versions: JUnit Core 1.1.6 >Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Major > Fix For: JUnit Core 1.1.8 > > > In the context of [PR > #20|https://github.com/apache/sling-org-apache-sling-junit-core/pull/20], it > turned out that a change between jupiter 5.10.0 and 5.10.1 brakes a test case. > I have identified the [relevant > change|https://github.com/junit-team/junit5/pull/3500/files#diff-eec44cb3c2bd65dc0944562c5b919097b7995cbbd874f3ff6f9cd1dd170a2814R1506-L1510] > to be stricter enforcement of a test method predicate. It turns out that we > have a meta-test (we're running tests within tests for o.a.s.junit.core) that > overrides and inherited test method, but does not itself add the `@Test` > annotation on it. That way the test method in question is not found, which > fails an assertion that checks if any meta-tests were run. > cc [~apelluru] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12162) Update o.a.s.junit.core to jupiter 5.10.1
[ https://issues.apache.org/jira/browse/SLING-12162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-12162: --- Fix Version/s: JUnit Core 1.1.8 > Update o.a.s.junit.core to jupiter 5.10.1 > - > > Key: SLING-12162 > URL: https://issues.apache.org/jira/browse/SLING-12162 > Project: Sling > Issue Type: Task > Components: JUnit Core >Affects Versions: JUnit Core 1.1.6 >Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Major > Fix For: JUnit Core 1.1.8 > > > In the context of [PR > #20|https://github.com/apache/sling-org-apache-sling-junit-core/pull/20], it > turned out that a change between jupiter 5.10.0 and 5.10.1 brakes a test case. > I have identified the [relevant > change|https://github.com/junit-team/junit5/pull/3500/files#diff-eec44cb3c2bd65dc0944562c5b919097b7995cbbd874f3ff6f9cd1dd170a2814R1506-L1510] > to be stricter enforcement of a test method predicate. It turns out that we > have a meta-test (we're running tests within tests for o.a.s.junit.core) that > overrides and inherited test method, but does not itself add the `@Test` > annotation on it. That way the test method in question is not found, which > fails an assertion that checks if any meta-tests were run. > cc [~apelluru] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12162) Update o.a.s.junit.core to jupiter 5.10.1
Julian Sedding created SLING-12162: -- Summary: Update o.a.s.junit.core to jupiter 5.10.1 Key: SLING-12162 URL: https://issues.apache.org/jira/browse/SLING-12162 Project: Sling Issue Type: Task Components: JUnit Core Affects Versions: JUnit Core 1.1.6 Reporter: Julian Sedding Assignee: Julian Sedding In the context of [PR #20|https://github.com/apache/sling-org-apache-sling-junit-core/pull/20], it turned out that a change between jupiter 5.10.0 and 5.10.1 brakes a test case. I have identified the [relevant change|https://github.com/junit-team/junit5/pull/3500/files#diff-eec44cb3c2bd65dc0944562c5b919097b7995cbbd874f3ff6f9cd1dd170a2814R1506-L1510] to be stricter enforcement of a test method predicate. It turns out that we have a meta-test (we're running tests within tests for o.a.s.junit.core) that overrides and inherited test method, but does not itself add the `@Test` annotation on it. That way the test method in question is not found, which fails an assertion that checks if any meta-tests were run. cc [~apelluru] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12115) Repoinit should leave importBehaviour for ACL creation to JCR
[
https://issues.apache.org/jira/browse/SLING-12115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding closed SLING-12115.
--
> Repoinit should leave importBehaviour for ACL creation to JCR
> -
>
> Key: SLING-12115
> URL: https://issues.apache.org/jira/browse/SLING-12115
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: Repoinit JCR 1.1.46
>
>
> JCR Repoinit checks the existence of the principal, for which ACLs should be
> created. In an Oak repository, this check depends on the {{ImportBehaviour}}
> configured for the {{SecurityProvider}}. JCR Repoinit should not check, but
> instead rely on the repository's behaviour.
> cc [~angela]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12107) JCR Repoinit executes operations out of order
[
https://issues.apache.org/jira/browse/SLING-12107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding closed SLING-12107.
--
> JCR Repoinit executes operations out of order
> -
>
> Key: SLING-12107
> URL: https://issues.apache.org/jira/browse/SLING-12107
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: Repoinit JCR 1.1.46
>
>
> When applying ACLs, repoinit checks if the referenced authorizable exists,
> and it fails if it doesn't.
> However, my goal was to set up ACLs with my deployment for a group that was
> to be sync'ed from an {{ExternalIdentityProvider}} once the first member of
> that group logs in.
> To work around this limitation, I tried running the following repoinit script:
> {noformat}
> create group testGroup
> set ACL for testGroup
> allow jcr:read on /content/foo
> deny jcr:write on /content/foo
> end
> delete group testGroup
> {noformat}
> It turned out that the statements were executed in the following order:
> {noformat}
> create group testGroup
> delete group testGroup
> set ACL for testGroup
> allow jcr:read on /content/foo
> deny jcr:write on /content/foo
> end
> {noformat}
> Of course that caused the script to fail just as if no group was created.
> The incorrect ordering may also cause other scenarios to fail.
> The {{ExecutionOrderTest}} suggests that some re-ordering is done on purpose.
> E.g. namespaces and nodetypes should be created before e.g. paths are created.
> I would expect that registration of custom privileges should also be executed
> before other operations. I don't see how that could be harmful.
> But for all other statements, I would expect the execution order to match the
> order of the statements within the repoinit script.
> cc [~bdelacretaz], [~cziegeler], [~angela]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12114) Update org.apache.sling.jcr.repoinit to parent pom 52
[ https://issues.apache.org/jira/browse/SLING-12114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-12114. -- > Update org.apache.sling.jcr.repoinit to parent pom 52 > - > > Key: SLING-12114 > URL: https://issues.apache.org/jira/browse/SLING-12114 > Project: Sling > Issue Type: Task > Components: Repoinit >Affects Versions: Repoinit JCR 1.1.44 >Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > Fix For: Repoinit JCR 1.1.46 > > > Update to parent pom version 52, update used and remove unnecessary > dependencies. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12122) Add unit-test creating group with rep:externalId property
[
https://issues.apache.org/jira/browse/SLING-12122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-12122:
---
Fix Version/s: Repoinit JCR 1.1.48
(was: Repoinit JCR 1.1.46)
> Add unit-test creating group with rep:externalId property
> -
>
> Key: SLING-12122
> URL: https://issues.apache.org/jira/browse/SLING-12122
> Project: Sling
> Issue Type: Test
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: Repoinit JCR 1.1.48
>
>
> Add a unit-test validating that repoinit can successfully create a new group
> with the {{rep:externalId}} property, that can only be set on creation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11621) Outdated JCR dependencies
[
https://issues.apache.org/jira/browse/SLING-11621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-11621:
---
Fix Version/s: Repoinit JCR 1.1.48
(was: Repoinit JCR 1.1.46)
> Outdated JCR dependencies
> -
>
> Key: SLING-11621
> URL: https://issues.apache.org/jira/browse/SLING-11621
> Project: Sling
> Issue Type: Task
> Components: Repoinit
>Reporter: Julian Reschke
>Priority: Major
> Fix For: Repoinit JCR 1.1.48
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> https://github.com/apache/sling-org-apache-sling-jcr-repoinit/blob/9913b787574186a7a31d184480cec3862816438f/pom.xml#L39:
> {noformat}
> 2.18.2
> 1.22.1
> {noformat}
> Jackrabbit 2.18 has been EOLd quite some time ago...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12157) [osgi-mock] late binding does not work for non-service DS components
Julian Sedding created SLING-12157:
--
Summary: [osgi-mock] late binding does not work for non-service DS
components
Key: SLING-12157
URL: https://issues.apache.org/jira/browse/SLING-12157
Project: Sling
Issue Type: Task
Components: Testing
Affects Versions: Testing OSGi Mock 3.3.10
Reporter: Julian Sedding
Assignee: Julian Sedding
A DS component that is not a service can be "injected" and "activated", but if
a service becomes available, that satisfies a dynamic reference, the "bind"
method is not called. The same should be true for the "unbind" scenario.
I observed this when I was registering a {{ResourceDecorator}} service in a
test case, and it did not get bound by the {{ResourceResolverFactoryActivator}}
that was already registered by the {{SlingContext}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12153) Update maven-archiver and maven-filtering
[
https://issues.apache.org/jira/browse/SLING-12153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785985#comment-17785985
]
Julian Sedding commented on SLING-12153:
The dependency in question is
{{org.eclipse.sisu:org.eclipse.sisu.plexus:0.0.0.M2a}}, which pulls in
{{com.google.guava:guava:10.0.1}}. After updating both the {{maven-archiver}}
and {{maven-filtering}} dependencies, the dependency to
{{org.eclipse.sisu:org.eclipse.sisu.plexus}} becomes a test dependency and thus
no longer appears in the transitive dependency graph.
The exception stack trace was:
{noformat}
java.lang.NoSuchMethodError: 'com.google.common.cache.CacheBuilder
com.google.common.cache.CacheBuilder.maximumSize(long)'
at
com.github.fge.jsonschema.core.load.SchemaLoader.(SchemaLoader.java:105)
at
com.github.fge.jsonschema.main.JsonSchemaFactory.(JsonSchemaFactory.java:138)
at
com.github.fge.jsonschema.main.JsonSchemaFactoryBuilder.freeze(JsonSchemaFactoryBuilder.java:139)
at
com.github.fge.jsonschema.main.JsonSchemaFactory.byDefault(JsonSchemaFactory.java:113)
at
org.apache.sling.feature.maven.Preprocessor.(Preprocessor.java:66)
at
org.apache.sling.feature.maven.mojos.DependencyLifecycleParticipant.afterProjectsRead(DependencyLifecycleParticipant.java:79)
at
org.jetbrains.idea.maven.server.utils.Maven3XProjectResolver.loadExtensions(Maven3XProjectResolver.java:391)
at
org.jetbrains.idea.maven.server.utils.Maven3XProjectResolver.lambda$doResolveProject$2(Maven3XProjectResolver.java:153)
at
org.jetbrains.idea.maven.server.Maven3ServerEmbedder.executeWithSessionScope(Maven3ServerEmbedder.java:289)
at
org.jetbrains.idea.maven.server.Maven3ServerEmbedder.executeWithMavenSession(Maven3ServerEmbedder.java:232)
at
org.jetbrains.idea.maven.server.utils.Maven3XProjectResolver.doResolveProject(Maven3XProjectResolver.java:117)
at
org.jetbrains.idea.maven.server.utils.Maven3XProjectResolver.resolveProjects(Maven3XProjectResolver.java:88)
at
org.jetbrains.idea.maven.server.Maven3XServerEmbedder.resolveProjects(Maven3XServerEmbedder.java:528)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:360)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
{noformat}
The problem is a signature change from {{CacheBuilder#maximumSize(int)}} to
{{CacheBuilder#maximumSize(long)}} somewhere between guava 10.0.1 and more
modern versions.
> Update maven-archiver and maven-filtering
> -
>
> Key: SLING-12153
> URL: https://issues.apache.org/jira/browse/SLING-12153
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: OSGi Feature Maven Plugin 1.8.2
>
>
> [~jsedding] noticed that the plug-in brings in older versions of the
> maven-archiver and maven-filtering. Those dependencies
> {quote}drag an ancient guava version into the classpath via a transitive
> dependency that was moved into "test" scope in newer versions of these two
> libraries{quote}
> This causes various problems with IntelliJ and Eclipse integration. And
> upgrading dependencies is always a good idea :-)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12114) Update org.apache.sling.jcr.repoinit to parent pom 52
[ https://issues.apache.org/jira/browse/SLING-12114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding resolved SLING-12114. Resolution: Fixed > Update org.apache.sling.jcr.repoinit to parent pom 52 > - > > Key: SLING-12114 > URL: https://issues.apache.org/jira/browse/SLING-12114 > Project: Sling > Issue Type: Task > Components: Repoinit >Affects Versions: Repoinit JCR 1.1.44 >Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > Fix For: Repoinit JCR 1.1.46 > > > Update to parent pom version 52, update used and remove unnecessary > dependencies. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12115) Repoinit should leave importBehaviour for ACL creation to JCR
[
https://issues.apache.org/jira/browse/SLING-12115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding resolved SLING-12115.
Resolution: Fixed
> Repoinit should leave importBehaviour for ACL creation to JCR
> -
>
> Key: SLING-12115
> URL: https://issues.apache.org/jira/browse/SLING-12115
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: Repoinit JCR 1.1.46
>
>
> JCR Repoinit checks the existence of the principal, for which ACLs should be
> created. In an Oak repository, this check depends on the {{ImportBehaviour}}
> configured for the {{SecurityProvider}}. JCR Repoinit should not check, but
> instead rely on the repository's behaviour.
> cc [~angela]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[
https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784238#comment-17784238
]
Julian Sedding commented on SLING-12131:
We have {{org.apache.sling.testing.osgi-mock}} and
{{org.apache.sling.testing.osgi-mock}} testing libraries, which each provide a
rule. You can find projects importing them with a [github
search|https://github.com/search?q=org%3Aapache+org.apache.sling.testing.osgi-mock+language%3A%22Maven+POM%22+-repo%3Aapache%2Fsling-whiteboard=code]
(adjust for sling-mock). Note, when JUnit5 came along, their respective junit4
(and thus rule-based) variants were renamed to
{{org.apache.sling.testing.osgi-mock.junit4}} and
{{{}org.apache.sling.testing.sling-mock.junit4{}}}.
There's also
[{{org.apache.sling.junit.teleporter}}|https://github.com/apache/sling-org-apache-sling-junit-teleporter],
not sure that's widely used, but it would be very difficult to rewrite for
JUnit5. You could search for usages of that one as well.
> Update sling-parent pom.xml to include JUnit5 dependencies
> --
>
> Key: SLING-12131
> URL: https://issues.apache.org/jira/browse/SLING-12131
> Project: Sling
> Issue Type: Task
>Reporter: Rob McDougall
>Priority: Major
>
> JUnit4 is in maintenance mode (no updates in the last 2 years and then only
> security fixes). I think updating projects to JUnit5 should be encouraged.
> I am thinking this should be a relatively easy change of adding the
> junit-jupiter and junit-vintage-engine into the Dependency Management section
> of the sling-parent.
> Once this is done, individual projects could switch to the vintage-engine (at
> the very least) or move to jupiter by switching the dependency in their
> project pom.
> Some day down the road, the JUnit 4 dependencies could be removed. Projects
> that have not updated to JUnit5 (vintage or jupiter) by that time are likely
> no longer maintained.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[
https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784213#comment-17784213
]
Julian Sedding edited comment on SLING-12131 at 11/8/23 9:49 PM:
-
{quote}Given that, unless anyone objects, I am going to create a PR for this.
{quote}
Go ahead! I think we have a clear consensus on that one.
{quote}I've used this before and it works well, [...]
{quote}
Glad to hear that!
{quote}Well, complete conversion to JUnit5 Jupiter should not be required
before the JUnit4 can be removed. Conversion to JUnit5 Vintage Engine should
handle custom @Rules and whatever other JUnit4 constructs are being used.
That's all I am talking about. Once that is done, the dependency on the
unmaintained JUnit4 is removed. Conversion from Vintage to Jupiter can take as
long as it takes.
{quote}
JUnit4 is not removed as long as you have the JUnit5 Vintage Engine. JUnit4 is
then just a transitive dependency and not explicitly in your pom. As long as
you are using @Rules, which are a JUnit4 API, you cannot remove the JUnit4
dependency. There is also {{{}junit-jupiter-migrationsupport{}}}, which can
emulate some JUnit4 rules. But again, that one does not remove the dependency
on the @Rule API provided by the JUnit4 dependency.
So I think we're finding common ground :) I'm conceding that migrating is
desirable, and you seem to be conceding that it's a best-effort exercise and
some parts of such a migration can be non-trivial.
was (Author: jsedding):
bq. Given that, unless anyone objects, I am going to create a PR for this.
Go ahead! I think we have a clear consencus on that one.
bq. I've used this before and it works well, [...]
Glad to hear that!
bq. Well, complete conversion to JUnit5 Jupiter should not be required before
the JUnit4 can be removed. Conversion to JUnit5 Vintage Engine should handle
custom @Rules and whatever other JUnit4 constructs are being used. That's all I
am talking about. Once that is done, the dependency on the unmaintained JUnit4
is removed. Conversion from Vintage to Jupiter can take as long as it takes.
JUnit4 is not removed as long as you have the JUnit5 Vintage Engine. JUnit4 is
then just a transitive dependency and not explicitly in your pom. As long as
you are using @Rules, which are a JUnit4 API, you cannot remove the JUnit4
dependency. There is also {{{}junit-jupiter-migrationsupport{}}}, which can
emulate some JUnit4 rules. But again, that one does not remove the dependency
on the @Rule API provided by the JUnit4 dependency.
So I think we're finding common ground :) I'm conceding that migrating is
desirable, and you seem to be conceding that it's a best-effort exercise and
some parts of such a migration can be non-trivial.
> Update sling-parent pom.xml to include JUnit5 dependencies
> --
>
> Key: SLING-12131
> URL: https://issues.apache.org/jira/browse/SLING-12131
> Project: Sling
> Issue Type: Task
>Reporter: Rob McDougall
>Priority: Major
>
> JUnit4 is in maintenance mode (no updates in the last 2 years and then only
> security fixes). I think updating projects to JUnit5 should be encouraged.
> I am thinking this should be a relatively easy change of adding the
> junit-jupiter and junit-vintage-engine into the Dependency Management section
> of the sling-parent.
> Once this is done, individual projects could switch to the vintage-engine (at
> the very least) or move to jupiter by switching the dependency in their
> project pom.
> Some day down the road, the JUnit 4 dependencies could be removed. Projects
> that have not updated to JUnit5 (vintage or jupiter) by that time are likely
> no longer maintained.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[
https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784213#comment-17784213
]
Julian Sedding edited comment on SLING-12131 at 11/8/23 9:49 PM:
-
bq. Given that, unless anyone objects, I am going to create a PR for this.
Go ahead! I think we have a clear consencus on that one.
bq. I've used this before and it works well, [...]
Glad to hear that!
bq. Well, complete conversion to JUnit5 Jupiter should not be required before
the JUnit4 can be removed. Conversion to JUnit5 Vintage Engine should handle
custom @Rules and whatever other JUnit4 constructs are being used. That's all I
am talking about. Once that is done, the dependency on the unmaintained JUnit4
is removed. Conversion from Vintage to Jupiter can take as long as it takes.
JUnit4 is not removed as long as you have the JUnit5 Vintage Engine. JUnit4 is
then just a transitive dependency and not explicitly in your pom. As long as
you are using @Rules, which are a JUnit4 API, you cannot remove the JUnit4
dependency. There is also {{{}junit-jupiter-migrationsupport{}}}, which can
emulate some JUnit4 rules. But again, that one does not remove the dependency
on the @Rule API provided by the JUnit4 dependency.
So I think we're finding common ground :) I'm conceding that migrating is
desirable, and you seem to be conceding that it's a best-effort exercise and
some parts of such a migration can be non-trivial.
was (Author: jsedding):
bq. I've used this before and it works well, [...]
Glad to hear that!
bq. Well, complete conversion to JUnit5 Jupiter should not be required before
the JUnit4 can be removed. Conversion to JUnit5 Vintage Engine should handle
custom @Rules and whatever other JUnit4 constructs are being used. That's all I
am talking about. Once that is done, the dependency on the unmaintained JUnit4
is removed. Conversion from Vintage to Jupiter can take as long as it takes.
JUnit4 is not removed as long as you have the JUnit5 Vintage Engine. JUnit4 is
then just a transitive dependency and not explicitly in your pom. As long as
you are using @Rules, which are a JUnit4 API, you cannot remove the JUnit4
dependency. There is also {{junit-jupiter-migrationsupport}}, which can emulate
some JUnit4 rules. But again, that one does not remove the dependency on the
@Rule API provided by the JUnit4 dependency.
So I think we're finding common ground :) I'm conceding that migrating is
desirable, and you seem to be conceding that it's a best-effort exercise and
some parts of such a migration can be non-trivial.
> Update sling-parent pom.xml to include JUnit5 dependencies
> --
>
> Key: SLING-12131
> URL: https://issues.apache.org/jira/browse/SLING-12131
> Project: Sling
> Issue Type: Task
>Reporter: Rob McDougall
>Priority: Major
>
> JUnit4 is in maintenance mode (no updates in the last 2 years and then only
> security fixes). I think updating projects to JUnit5 should be encouraged.
> I am thinking this should be a relatively easy change of adding the
> junit-jupiter and junit-vintage-engine into the Dependency Management section
> of the sling-parent.
> Once this is done, individual projects could switch to the vintage-engine (at
> the very least) or move to jupiter by switching the dependency in their
> project pom.
> Some day down the road, the JUnit 4 dependencies could be removed. Projects
> that have not updated to JUnit5 (vintage or jupiter) by that time are likely
> no longer maintained.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[
https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784213#comment-17784213
]
Julian Sedding commented on SLING-12131:
bq. I've used this before and it works well, [...]
Glad to hear that!
bq. Well, complete conversion to JUnit5 Jupiter should not be required before
the JUnit4 can be removed. Conversion to JUnit5 Vintage Engine should handle
custom @Rules and whatever other JUnit4 constructs are being used. That's all I
am talking about. Once that is done, the dependency on the unmaintained JUnit4
is removed. Conversion from Vintage to Jupiter can take as long as it takes.
JUnit4 is not removed as long as you have the JUnit5 Vintage Engine. JUnit4 is
then just a transitive dependency and not explicitly in your pom. As long as
you are using @Rules, which are a JUnit4 API, you cannot remove the JUnit4
dependency. There is also {{junit-jupiter-migrationsupport}}, which can emulate
some JUnit4 rules. But again, that one does not remove the dependency on the
@Rule API provided by the JUnit4 dependency.
So I think we're finding common ground :) I'm conceding that migrating is
desirable, and you seem to be conceding that it's a best-effort exercise and
some parts of such a migration can be non-trivial.
> Update sling-parent pom.xml to include JUnit5 dependencies
> --
>
> Key: SLING-12131
> URL: https://issues.apache.org/jira/browse/SLING-12131
> Project: Sling
> Issue Type: Task
>Reporter: Rob McDougall
>Priority: Major
>
> JUnit4 is in maintenance mode (no updates in the last 2 years and then only
> security fixes). I think updating projects to JUnit5 should be encouraged.
> I am thinking this should be a relatively easy change of adding the
> junit-jupiter and junit-vintage-engine into the Dependency Management section
> of the sling-parent.
> Once this is done, individual projects could switch to the vintage-engine (at
> the very least) or move to jupiter by switching the dependency in their
> project pom.
> Some day down the road, the JUnit 4 dependencies could be removed. Projects
> that have not updated to JUnit5 (vintage or jupiter) by that time are likely
> no longer maintained.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12126) Update o.a.s.repoinit.parser to 1.9.0 in feature model analyzer
[ https://issues.apache.org/jira/browse/SLING-12126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-12126. -- > Update o.a.s.repoinit.parser to 1.9.0 in feature model analyzer > --- > > Key: SLING-12126 > URL: https://issues.apache.org/jira/browse/SLING-12126 > Project: Sling > Issue Type: Task > Components: Feature Model Analyser >Affects Versions: Feature Model Analyser 2.0.0 >Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > Fix For: Feature Model Analyser 2.0.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11935) JarDecompressorTest.testWithEmbeddedJar fails on Jenkins/Windows
[
https://issues.apache.org/jira/browse/SLING-11935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding closed SLING-11935.
--
> JarDecompressorTest.testWithEmbeddedJar fails on Jenkins/Windows
>
>
> Key: SLING-11935
> URL: https://issues.apache.org/jira/browse/SLING-11935
> Project: Sling
> Issue Type: Bug
> Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Robert Munteanu
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: OSGi Feature Maven Plugin 1.7.4
>
>
> This is the only CI failure, but I don't understand enough about the
> JarDecompressor to make an informed fix. I will ignore the test on Windows
> for now, but it would be great to understand the root cause and fix it.
> {noformat}[ERROR]
> org.apache.sling.feature.maven.mojos.JarDecompressorTest.testJarWithEmbeddedJar
> Time elapsed: 0.071 s <<< FAILURE!
> java.lang.AssertionError: expected:<2108> but was:<1984>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.sling.feature.maven.mojos.JarDecompressorTest.testJarWithEmbeddedJar(JarDecompressorTest.java:81)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:364)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:237)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:158)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-11947) Convert Plexus to JSR330 components
[ https://issues.apache.org/jira/browse/SLING-11947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-11947. -- > Convert Plexus to JSR330 components > --- > > Key: SLING-11947 > URL: https://issues.apache.org/jira/browse/SLING-11947 > Project: Sling > Issue Type: Improvement > Components: Maven Plugins and Archetypes >Affects Versions: OSGi Feature Maven Plugin 1.7.2 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: OSGi Feature Maven Plugin 1.7.4 > > > As Plexus component descriptors are deprecated > (https://codehaus-plexus.github.io/plexus-containers/#deprecated) one should > migrate instead to the standard JSR330 annotations which are evaluated at run > time (https://github.com/eclipse/sisu.plexus/wiki/Plexus-to-JSR330) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11948) Get rid of legacy maven-compat dependency
[ https://issues.apache.org/jira/browse/SLING-11948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-11948. -- > Get rid of legacy maven-compat dependency > - > > Key: SLING-11948 > URL: https://issues.apache.org/jira/browse/SLING-11948 > Project: Sling > Issue Type: Improvement > Components: Maven Plugins and Archetypes >Affects Versions: OSGi Feature Maven Plugin 1.7.2 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: OSGi Feature Maven Plugin 1.7.4 > > > This involves leveraging Maven Resolver API directly. Using legacy > maven-compat leads to a WARN with Maven 3.9.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11987) Allow report into a single file
[ https://issues.apache.org/jira/browse/SLING-11987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-11987. -- > Allow report into a single file > --- > > Key: SLING-11987 > URL: https://issues.apache.org/jira/browse/SLING-11987 > Project: Sling > Issue Type: New Feature > Components: Feature Model, Maven Plugins and Archetypes >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: OSGi Feature Maven Plugin 1.7.4 > > > The feature report can either be outputted into the normal log output or into > separate report files per feature. > Sometimes it is useful to get a single report across all features -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-9883) ApisJarMojo: Provide-Capability should be collected from all contained bundles and exposed
[
https://issues.apache.org/jira/browse/SLING-9883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding closed SLING-9883.
-
> ApisJarMojo: Provide-Capability should be collected from all contained
> bundles and exposed
> --
>
> Key: SLING-9883
> URL: https://issues.apache.org/jira/browse/SLING-9883
> Project: Sling
> Issue Type: Improvement
> Components: Feature Model
>Affects Versions: slingfeature-maven-plugin 1.4.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: OSGi Feature Maven Plugin 1.7.4
>
>
> In order to leverage
> https://github.com/bndtools/bnd/tree/master/maven/bnd-resolver-maven-plugin
> at build time it would be nice if the API jar would include the
> {{Provide-Capability}} headers from all contained bundles (similar to
> {{Export-Package}} and {{Sling-Nodetypes}}).
> See also
> https://lists.apache.org/thread.html/r7bb5c4493fa241ac5cd8d8ea313ff970866e2f2efc6254ee6a0fd41a%40%3Cdev.sling.apache.org%3E
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12009) Report errors and warnings at the end of the scan
[ https://issues.apache.org/jira/browse/SLING-12009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-12009. -- > Report errors and warnings at the end of the scan > - > > Key: SLING-12009 > URL: https://issues.apache.org/jira/browse/SLING-12009 > Project: Sling > Issue Type: Improvement > Components: Maven Plugins and Archetypes >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: OSGi Feature Maven Plugin 1.7.4 > > > Especially when a lot of features get analysed, the errors and warnings are > "hidden" in between all the analysis runs. This makes it sometimes hard to > find them. > The report could be deferred to the end of the scan -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11985) Add report about imported packages
[ https://issues.apache.org/jira/browse/SLING-11985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-11985. -- > Add report about imported packages > -- > > Key: SLING-11985 > URL: https://issues.apache.org/jira/browse/SLING-11985 > Project: Sling > Issue Type: New Feature > Components: Feature Model, Maven Plugins and Archetypes >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: OSGi Feature Maven Plugin 1.7.4 > > > We only have a report for exported packages; sometimes it is also useful to > get info about all imported packages -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12127) Update o.a.s.repoinit.parser to 1.9.0 in slingfeature-maven-plugin
[ https://issues.apache.org/jira/browse/SLING-12127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-12127. -- > Update o.a.s.repoinit.parser to 1.9.0 in slingfeature-maven-plugin > -- > > Key: SLING-12127 > URL: https://issues.apache.org/jira/browse/SLING-12127 > Project: Sling > Issue Type: Task > Components: Feature Model, Maven Plugins and Archetypes >Affects Versions: OSGi Feature Maven Plugin 1.7.2 >Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > Fix For: OSGi Feature Maven Plugin 1.7.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[
https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784146#comment-17784146
]
Julian Sedding commented on SLING-12131:
If migration is the goal, then it may make sense to facilitate semi-automated
migration. A quick google turned up that the OpenRewrite projct has several
[rules for migrating various
scenarios|https://docs.openrewrite.org/recipes/java/testing/junit5]. There is a
maven plugin, so we could add a configuration to the parent pom. IIUC it is
[invoked using {{mvn
rewrite:run}}|https://docs.openrewrite.org/running-recipes/getting-started#step-4-run-a-simple-refactoring-recipe].
We could also put the plugin into a profile, if we want to guard against any
surprises.
I agree that it would be desirable to migrate all actively maintained modules
to junit5. That said, I don't believe it is realistic in the foreseeable
future, most certainly not without automation. There are custom {{@Rule}}
implementations that are non-trivial to migrate. There are runners, that may
not be trivial to migrate, either. The difference between assertions and some
ootb {{@Rule}}s can likely be covered with automation. Remains to be seen how
well the automation works.
> Update sling-parent pom.xml to include JUnit5 dependencies
> --
>
> Key: SLING-12131
> URL: https://issues.apache.org/jira/browse/SLING-12131
> Project: Sling
> Issue Type: Task
>Reporter: Rob McDougall
>Priority: Major
>
> JUnit4 is in maintenance mode (no updates in the last 2 years and then only
> security fixes). I think updating projects to JUnit5 should be encouraged.
> I am thinking this should be a relatively easy change of adding the
> junit-jupiter and junit-vintage-engine into the Dependency Management section
> of the sling-parent.
> Once this is done, individual projects could switch to the vintage-engine (at
> the very least) or move to jupiter by switching the dependency in their
> project pom.
> Some day down the road, the JUnit 4 dependencies could be removed. Projects
> that have not updated to JUnit5 (vintage or jupiter) by that time are likely
> no longer maintained.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[ https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784022#comment-17784022 ] Julian Sedding commented on SLING-12131: bq. Let us please just import the JUnit BOM [...] +1 from me > Update sling-parent pom.xml to include JUnit5 dependencies > -- > > Key: SLING-12131 > URL: https://issues.apache.org/jira/browse/SLING-12131 > Project: Sling > Issue Type: Task >Reporter: Rob McDougall >Priority: Major > > JUnit4 is in maintenance mode (no updates in the last 2 years and then only > security fixes). I think updating projects to JUnit5 should be encouraged. > I am thinking this should be a relatively easy change of adding the > junit-jupiter and junit-vintage-engine into the Dependency Management section > of the sling-parent. > Once this is done, individual projects could switch to the vintage-engine (at > the very least) or move to jupiter by switching the dependency in their > project pom. > Some day down the road, the JUnit 4 dependencies could be removed. Projects > that have not updated to JUnit5 (vintage or jupiter) by that time are likely > no longer maintained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[ https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784016#comment-17784016 ] Julian Sedding edited comment on SLING-12131 at 11/8/23 12:35 PM: -- AFAIK the latest maven-surefire-plugin automatically adds the jupiter and vintage engines if the jupiter-api and the junit api, respectively, are in the dependencies. I would also like to transition more to junit5/jupiter, and since you can even mix and match individual test methods within the same class, I see no reason why we shouldn't move forward with it. I would add the following two dependencies to sling-parent: - org.junit.jupiter:junit-jupiter-api - org.junit.jupiter:junit-jupiter-params bq. Some day down the road, the JUnit 4 dependencies could be removed. Projects that have not updated to JUnit5 (vintage or jupiter) by that time are likely no longer maintained. Yes, we could eventually remove JUnit 4 from the parent. But I disagree with the rest of the statement. IMHO, it is _very_ unlikely that we find the time and resources to migrate all tests to junit5. Also, there is virtually no value in doing so, because you can use junit4 and junit5 side-by-side. Therefore, in my eyes, concluding whether or not a module is maintained, will be independent of whether it uses junit4 or junit5. was (Author: jsedding): AFAIK the latest maven-surefire-plugin automatically adds the jupiter and vintage engines if the jupiter-api and the junit api, respectively, are in the dependencies. I would also like to transition more to junit5/jupiter, and since you can even mix and match individual test methods within the same class, I see no reason why we shouldn't move forward with it. I would add the following two dependencies to sling-parent: - org.junit.jupiter:junit-jupiter-api - org.junit.jupiter:junit-jupiter-params > Update sling-parent pom.xml to include JUnit5 dependencies > -- > > Key: SLING-12131 > URL: https://issues.apache.org/jira/browse/SLING-12131 > Project: Sling > Issue Type: Task >Reporter: Rob McDougall >Priority: Major > > JUnit4 is in maintenance mode (no updates in the last 2 years and then only > security fixes). I think updating projects to JUnit5 should be encouraged. > I am thinking this should be a relatively easy change of adding the > junit-jupiter and junit-vintage-engine into the Dependency Management section > of the sling-parent. > Once this is done, individual projects could switch to the vintage-engine (at > the very least) or move to jupiter by switching the dependency in their > project pom. > Some day down the road, the JUnit 4 dependencies could be removed. Projects > that have not updated to JUnit5 (vintage or jupiter) by that time are likely > no longer maintained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies
[ https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784016#comment-17784016 ] Julian Sedding commented on SLING-12131: AFAIK the latest maven-surefire-plugin automatically adds the jupiter and vintage engines if the jupiter-api and the junit api, respectively, are in the dependencies. I would also like to transition more to junit5/jupiter, and since you can even mix and match individual test methods within the same class, I see no reason why we shouldn't move forward with it. I would add the following two dependencies to sling-parent: - org.junit.jupiter:junit-jupiter-api - org.junit.jupiter:junit-jupiter-params > Update sling-parent pom.xml to include JUnit5 dependencies > -- > > Key: SLING-12131 > URL: https://issues.apache.org/jira/browse/SLING-12131 > Project: Sling > Issue Type: Task >Reporter: Rob McDougall >Priority: Major > > JUnit4 is in maintenance mode (no updates in the last 2 years and then only > security fixes). I think updating projects to JUnit5 should be encouraged. > I am thinking this should be a relatively easy change of adding the > junit-jupiter and junit-vintage-engine into the Dependency Management section > of the sling-parent. > Once this is done, individual projects could switch to the vintage-engine (at > the very least) or move to jupiter by switching the dependency in their > project pom. > Some day down the road, the JUnit 4 dependencies could be removed. Projects > that have not updated to JUnit5 (vintage or jupiter) by that time are likely > no longer maintained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12107) JCR Repoinit executes operations out of order
[
https://issues.apache.org/jira/browse/SLING-12107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding resolved SLING-12107.
Resolution: Fixed
> JCR Repoinit executes operations out of order
> -
>
> Key: SLING-12107
> URL: https://issues.apache.org/jira/browse/SLING-12107
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: Repoinit JCR 1.1.46
>
>
> When applying ACLs, repoinit checks if the referenced authorizable exists,
> and it fails if it doesn't.
> However, my goal was to set up ACLs with my deployment for a group that was
> to be sync'ed from an {{ExternalIdentityProvider}} once the first member of
> that group logs in.
> To work around this limitation, I tried running the following repoinit script:
> {noformat}
> create group testGroup
> set ACL for testGroup
> allow jcr:read on /content/foo
> deny jcr:write on /content/foo
> end
> delete group testGroup
> {noformat}
> It turned out that the statements were executed in the following order:
> {noformat}
> create group testGroup
> delete group testGroup
> set ACL for testGroup
> allow jcr:read on /content/foo
> deny jcr:write on /content/foo
> end
> {noformat}
> Of course that caused the script to fail just as if no group was created.
> The incorrect ordering may also cause other scenarios to fail.
> The {{ExecutionOrderTest}} suggests that some re-ordering is done on purpose.
> E.g. namespaces and nodetypes should be created before e.g. paths are created.
> I would expect that registration of custom privileges should also be executed
> before other operations. I don't see how that could be harmful.
> But for all other statements, I would expect the execution order to match the
> order of the statements within the repoinit script.
> cc [~bdelacretaz], [~cziegeler], [~angela]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12127) Update o.a.s.repoinit.parser to 1.9.0 in slingfeature-maven-plugin
[ https://issues.apache.org/jira/browse/SLING-12127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-12127: --- Affects Version/s: OSGi Feature Maven Plugin 1.7.2 (was: slingfeature-maven-plugin 1.6.8) > Update o.a.s.repoinit.parser to 1.9.0 in slingfeature-maven-plugin > -- > > Key: SLING-12127 > URL: https://issues.apache.org/jira/browse/SLING-12127 > Project: Sling > Issue Type: Task > Components: Feature Model, Maven Plugins and Archetypes >Affects Versions: OSGi Feature Maven Plugin 1.7.2 >Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > Fix For: OSGi Feature Maven Plugin 1.7.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12127) Update o.a.s.repoinit.parser to 1.9.0 in slingfeature-maven-plugin
[ https://issues.apache.org/jira/browse/SLING-12127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding resolved SLING-12127. Resolution: Fixed > Update o.a.s.repoinit.parser to 1.9.0 in slingfeature-maven-plugin > -- > > Key: SLING-12127 > URL: https://issues.apache.org/jira/browse/SLING-12127 > Project: Sling > Issue Type: Task > Components: Feature Model, Maven Plugins and Archetypes >Affects Versions: slingfeature-maven-plugin 1.6.8 >Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > Fix For: OSGi Feature Maven Plugin 1.7.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12127) Update o.a.s.repoinit.parser to 1.9.0 in slingfeature-maven-plugin
[ https://issues.apache.org/jira/browse/SLING-12127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-12127: --- Fix Version/s: OSGi Feature Maven Plugin 1.7.4 (was: slingfeature-maven-plugin 1.6.10) > Update o.a.s.repoinit.parser to 1.9.0 in slingfeature-maven-plugin > -- > > Key: SLING-12127 > URL: https://issues.apache.org/jira/browse/SLING-12127 > Project: Sling > Issue Type: Task > Components: Feature Model, Maven Plugins and Archetypes >Affects Versions: slingfeature-maven-plugin 1.6.8 >Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > Fix For: OSGi Feature Maven Plugin 1.7.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12126) Update o.a.s.repoinit.parser to 1.9.0 in feature model analyzer
[ https://issues.apache.org/jira/browse/SLING-12126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding resolved SLING-12126. Resolution: Fixed Fixed in [PR #44|https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/44]. > Update o.a.s.repoinit.parser to 1.9.0 in feature model analyzer > --- > > Key: SLING-12126 > URL: https://issues.apache.org/jira/browse/SLING-12126 > Project: Sling > Issue Type: Task > Components: Feature Model Analyser >Affects Versions: Feature Model Analyser 2.0.0 >Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > Fix For: Feature Model Analyser 2.0.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12127) Update o.a.s.repoinit.parser to 1.9.0 in slingfeature-maven-plugin
[ https://issues.apache.org/jira/browse/SLING-12127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-12127: --- Fix Version/s: slingfeature-maven-plugin 1.6.10 > Update o.a.s.repoinit.parser to 1.9.0 in slingfeature-maven-plugin > -- > > Key: SLING-12127 > URL: https://issues.apache.org/jira/browse/SLING-12127 > Project: Sling > Issue Type: Task > Components: Feature Model, Maven Plugins and Archetypes >Affects Versions: slingfeature-maven-plugin 1.6.8 >Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > Fix For: slingfeature-maven-plugin 1.6.10 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12127) Update o.a.s.repoinit.parser to 1.9.0 in slingfeature-maven-plugin
Julian Sedding created SLING-12127: -- Summary: Update o.a.s.repoinit.parser to 1.9.0 in slingfeature-maven-plugin Key: SLING-12127 URL: https://issues.apache.org/jira/browse/SLING-12127 Project: Sling Issue Type: Task Components: Feature Model, Maven Plugins and Archetypes Affects Versions: slingfeature-maven-plugin 1.6.8 Reporter: Julian Sedding Assignee: Julian Sedding -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12126) Update o.a.s.repoinit.parser to 1.9.0 in feature model analyzer
Julian Sedding created SLING-12126: -- Summary: Update o.a.s.repoinit.parser to 1.9.0 in feature model analyzer Key: SLING-12126 URL: https://issues.apache.org/jira/browse/SLING-12126 Project: Sling Issue Type: Task Components: Feature Model Analyser Affects Versions: Feature Model Analyser 2.0.0 Reporter: Julian Sedding Assignee: Julian Sedding Fix For: Feature Model Analyser 2.0.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12107) JCR Repoinit executes operations out of order
[
https://issues.apache.org/jira/browse/SLING-12107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782080#comment-17782080
]
Julian Sedding commented on SLING-12107:
[~kwin] I added a paragraph about ordering in [sling-site PR
#143|https://github.com/apache/sling-site/pull/143].
[~cziegeler] here's what I intend to add to the docs:
{quote}
When a repoinit script is applied with the `org.apache.sling.jcr.repoinit`
module, the execution order of the individual
statements is slightly different from their order within the script. Namely,
all statements creating namespaces are
executed before any other statements. Next, all statements registering
nodetypes or privileges are executed. And finally,
all other statements are executed in the order they are defined. This
reordering is intended to avoid issues due to
missing namespaces, nodetypes or privileges when content is created.
{quote}
> JCR Repoinit executes operations out of order
> -
>
> Key: SLING-12107
> URL: https://issues.apache.org/jira/browse/SLING-12107
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: Repoinit JCR 1.1.46
>
>
> When applying ACLs, repoinit checks if the referenced authorizable exists,
> and it fails if it doesn't.
> However, my goal was to set up ACLs with my deployment for a group that was
> to be sync'ed from an {{ExternalIdentityProvider}} once the first member of
> that group logs in.
> To work around this limitation, I tried running the following repoinit script:
> {noformat}
> create group testGroup
> set ACL for testGroup
> allow jcr:read on /content/foo
> deny jcr:write on /content/foo
> end
> delete group testGroup
> {noformat}
> It turned out that the statements were executed in the following order:
> {noformat}
> create group testGroup
> delete group testGroup
> set ACL for testGroup
> allow jcr:read on /content/foo
> deny jcr:write on /content/foo
> end
> {noformat}
> Of course that caused the script to fail just as if no group was created.
> The incorrect ordering may also cause other scenarios to fail.
> The {{ExecutionOrderTest}} suggests that some re-ordering is done on purpose.
> E.g. namespaces and nodetypes should be created before e.g. paths are created.
> I would expect that registration of custom privileges should also be executed
> before other operations. I don't see how that could be harmful.
> But for all other statements, I would expect the execution order to match the
> order of the statements within the repoinit script.
> cc [~bdelacretaz], [~cziegeler], [~angela]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12115) Repoinit should leave importBehaviour for ACL creation to JCR
[
https://issues.apache.org/jira/browse/SLING-12115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782073#comment-17782073
]
Julian Sedding commented on SLING-12115:
I have now implemented this using {{ACLOptions}} as suggested by [~kwin]. I.e.
the following two variations of the syntax are supported.
{noformat}
set ACL on / (ACLOptions=ignoreMissingPrincipal)
...
end
set ACL for nonExistingPrincipal (ACLOptions=ignoreMissingPrincipal)
...
end
{noformat}
> Repoinit should leave importBehaviour for ACL creation to JCR
> -
>
> Key: SLING-12115
> URL: https://issues.apache.org/jira/browse/SLING-12115
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: Repoinit JCR 1.1.46
>
>
> JCR Repoinit checks the existence of the principal, for which ACLs should be
> created. In an Oak repository, this check depends on the {{ImportBehaviour}}
> configured for the {{SecurityProvider}}. JCR Repoinit should not check, but
> instead rely on the repository's behaviour.
> cc [~angela]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12122) Add unit-test creating group with rep:externalId property
Julian Sedding created SLING-12122:
--
Summary: Add unit-test creating group with rep:externalId property
Key: SLING-12122
URL: https://issues.apache.org/jira/browse/SLING-12122
Project: Sling
Issue Type: Test
Components: Repoinit
Affects Versions: Repoinit JCR 1.1.44
Reporter: Julian Sedding
Assignee: Julian Sedding
Fix For: Repoinit JCR 1.1.46
Add a unit-test validating that repoinit can successfully create a new group
with the {{rep:externalId}} property, that can only be set on creation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12107) JCR Repoinit executes operations out of order
[
https://issues.apache.org/jira/browse/SLING-12107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-12107:
---
Fix Version/s: Repoinit JCR 1.1.46
> JCR Repoinit executes operations out of order
> -
>
> Key: SLING-12107
> URL: https://issues.apache.org/jira/browse/SLING-12107
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: Repoinit JCR 1.1.46
>
>
> When applying ACLs, repoinit checks if the referenced authorizable exists,
> and it fails if it doesn't.
> However, my goal was to set up ACLs with my deployment for a group that was
> to be sync'ed from an {{ExternalIdentityProvider}} once the first member of
> that group logs in.
> To work around this limitation, I tried running the following repoinit script:
> {noformat}
> create group testGroup
> set ACL for testGroup
> allow jcr:read on /content/foo
> deny jcr:write on /content/foo
> end
> delete group testGroup
> {noformat}
> It turned out that the statements were executed in the following order:
> {noformat}
> create group testGroup
> delete group testGroup
> set ACL for testGroup
> allow jcr:read on /content/foo
> deny jcr:write on /content/foo
> end
> {noformat}
> Of course that caused the script to fail just as if no group was created.
> The incorrect ordering may also cause other scenarios to fail.
> The {{ExecutionOrderTest}} suggests that some re-ordering is done on purpose.
> E.g. namespaces and nodetypes should be created before e.g. paths are created.
> I would expect that registration of custom privileges should also be executed
> before other operations. I don't see how that could be harmful.
> But for all other statements, I would expect the execution order to match the
> order of the statements within the repoinit script.
> cc [~bdelacretaz], [~cziegeler], [~angela]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12107) JCR Repoinit executes operations out of order
[
https://issues.apache.org/jira/browse/SLING-12107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-12107:
---
Issue Type: Bug (was: Task)
> JCR Repoinit executes operations out of order
> -
>
> Key: SLING-12107
> URL: https://issues.apache.org/jira/browse/SLING-12107
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
>
> When applying ACLs, repoinit checks if the referenced authorizable exists,
> and it fails if it doesn't.
> However, my goal was to set up ACLs with my deployment for a group that was
> to be sync'ed from an {{ExternalIdentityProvider}} once the first member of
> that group logs in.
> To work around this limitation, I tried running the following repoinit script:
> {noformat}
> create group testGroup
> set ACL for testGroup
> allow jcr:read on /content/foo
> deny jcr:write on /content/foo
> end
> delete group testGroup
> {noformat}
> It turned out that the statements were executed in the following order:
> {noformat}
> create group testGroup
> delete group testGroup
> set ACL for testGroup
> allow jcr:read on /content/foo
> deny jcr:write on /content/foo
> end
> {noformat}
> Of course that caused the script to fail just as if no group was created.
> The incorrect ordering may also cause other scenarios to fail.
> The {{ExecutionOrderTest}} suggests that some re-ordering is done on purpose.
> E.g. namespaces and nodetypes should be created before e.g. paths are created.
> I would expect that registration of custom privileges should also be executed
> before other operations. I don't see how that could be harmful.
> But for all other statements, I would expect the execution order to match the
> order of the statements within the repoinit script.
> cc [~bdelacretaz], [~cziegeler], [~angela]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12115) Repoinit should leave importBehaviour for ACL creation to JCR
Julian Sedding created SLING-12115:
--
Summary: Repoinit should leave importBehaviour for ACL creation to
JCR
Key: SLING-12115
URL: https://issues.apache.org/jira/browse/SLING-12115
Project: Sling
Issue Type: Bug
Components: Repoinit
Affects Versions: Repoinit JCR 1.1.44
Reporter: Julian Sedding
Assignee: Julian Sedding
Fix For: Repoinit JCR 1.1.46
JCR Repoinit checks the existence of the principal, for which ACLs should be
created. In an Oak repository, this check depends on the {{ImportBehaviour}}
configured for the {{SecurityProvider}}. JCR Repoinit should not check, but
instead rely on the repository's behaviour.
cc [~angela]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12114) Update org.apache.sling.jcr.repoinit to parent pom 52
Julian Sedding created SLING-12114: -- Summary: Update org.apache.sling.jcr.repoinit to parent pom 52 Key: SLING-12114 URL: https://issues.apache.org/jira/browse/SLING-12114 Project: Sling Issue Type: Task Components: Repoinit Affects Versions: Repoinit JCR 1.1.44 Reporter: Julian Sedding Assignee: Julian Sedding Fix For: Repoinit JCR 1.1.46 Update to parent pom version 52, update used and remove unnecessary dependencies. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12107) JCR Repoinit executes operations out of order
[
https://issues.apache.org/jira/browse/SLING-12107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-12107:
---
Summary: JCR Repoinit executes operations out of order (was: JCR Repoinit
executes operations out of order.)
> JCR Repoinit executes operations out of order
> -
>
> Key: SLING-12107
> URL: https://issues.apache.org/jira/browse/SLING-12107
> Project: Sling
> Issue Type: Task
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
>
> When applying ACLs, repoinit checks if the referenced authorizable exists,
> and it fails if it doesn't.
> However, my goal was to set up ACLs with my deployment for a group that was
> to be sync'ed from an {{ExternalIdentityProvider}} once the first member of
> that group logs in.
> To work around this limitation, I tried running the following repoinit script:
> {noformat}
> create group testGroup
> set ACL for testGroup
> allow jcr:read on /content/foo
> deny jcr:write on /content/foo
> end
> delete group testGroup
> {noformat}
> It turned out that the statements were executed in the following order:
> {noformat}
> create group testGroup
> delete group testGroup
> set ACL for testGroup
> allow jcr:read on /content/foo
> deny jcr:write on /content/foo
> end
> {noformat}
> Of course that caused the script to fail just as if no group was created.
> The incorrect ordering may also cause other scenarios to fail.
> The {{ExecutionOrderTest}} suggests that some re-ordering is done on purpose.
> E.g. namespaces and nodetypes should be created before e.g. paths are created.
> I would expect that registration of custom privileges should also be executed
> before other operations. I don't see how that could be harmful.
> But for all other statements, I would expect the execution order to match the
> order of the statements within the repoinit script.
> cc [~bdelacretaz], [~cziegeler], [~angela]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12107) JCR Repoinit executes operations out of order.
Julian Sedding created SLING-12107:
--
Summary: JCR Repoinit executes operations out of order.
Key: SLING-12107
URL: https://issues.apache.org/jira/browse/SLING-12107
Project: Sling
Issue Type: Task
Components: Repoinit
Affects Versions: Repoinit JCR 1.1.44
Reporter: Julian Sedding
Assignee: Julian Sedding
When applying ACLs, repoinit checks if the referenced authorizable exists, and
it fails if it doesn't.
However, my goal was to set up ACLs with my deployment for a group that was to
be sync'ed from an {{ExternalIdentityProvider}} once the first member of that
group logs in.
To work around this limitation, I tried running the following repoinit script:
{noformat}
create group testGroup
set ACL for testGroup
allow jcr:read on /content/foo
deny jcr:write on /content/foo
end
delete group testGroup
{noformat}
It turned out that the statements were executed in the following order:
{noformat}
create group testGroup
delete group testGroup
set ACL for testGroup
allow jcr:read on /content/foo
deny jcr:write on /content/foo
end
{noformat}
Of course that caused the script to fail just as if no group was created.
The incorrect ordering may also cause other scenarios to fail.
The {{ExecutionOrderTest}} suggests that some re-ordering is done on purpose.
E.g. namespaces and nodetypes should be created before e.g. paths are created.
I would expect that registration of custom privileges should also be executed
before other operations. I don't see how that could be harmful.
But for all other statements, I would expect the execution order to match the
order of the statements within the repoinit script.
cc [~bdelacretaz], [~cziegeler], [~angela]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12046) Update org.apache.sling.jcr.base to parent pom 52
Julian Sedding created SLING-12046: -- Summary: Update org.apache.sling.jcr.base to parent pom 52 Key: SLING-12046 URL: https://issues.apache.org/jira/browse/SLING-12046 Project: Sling Issue Type: Task Components: JCR Affects Versions: JCR Base 3.1.14 Reporter: Julian Sedding Assignee: Julian Sedding Update org.apache.sling.jcr.base to parent pom 52. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12046) Update org.apache.sling.jcr.base to parent pom 52
[ https://issues.apache.org/jira/browse/SLING-12046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-12046: --- Description: Update org.apache.sling.jcr.base to parent pom 52 in order to allow the module to build on java 17. (was: Update org.apache.sling.jcr.base to parent pom 52.) > Update org.apache.sling.jcr.base to parent pom 52 > - > > Key: SLING-12046 > URL: https://issues.apache.org/jira/browse/SLING-12046 > Project: Sling > Issue Type: Task > Components: JCR >Affects Versions: JCR Base 3.1.14 >Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > > Update org.apache.sling.jcr.base to parent pom 52 in order to allow the > module to build on java 17. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11756) resource resolver: rewrite getVanityPathDefinition for more clarity
[ https://issues.apache.org/jira/browse/SLING-11756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-11756. -- > resource resolver: rewrite getVanityPathDefinition for more clarity > > > Key: SLING-11756 > URL: https://issues.apache.org/jira/browse/SLING-11756 > Project: Sling > Issue Type: Sub-task > Components: ResourceResolver >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Trivial > Fix For: Resource Resolver 1.11.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12020) resource resolver: alias metric has confusing name
[ https://issues.apache.org/jira/browse/SLING-12020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-12020. -- > resource resolver: alias metric has confusing name > -- > > Key: SLING-12020 > URL: https://issues.apache.org/jira/browse/SLING-12020 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: Resource Resolver 1.11.0 > > > The metric "numberOfAliases" has a very very misleading name; actually it's > the number of nodes that have any number of child nodes with aliases. So, > this could be a magnitude less than the actual number of aliases. > Rename? Fix? (that would require counting instead of just returning the map > size) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11541) vanity path query: attempt to query sorted by first vanity path, check results
[ https://issues.apache.org/jira/browse/SLING-11541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-11541. -- > vanity path query: attempt to query sorted by first vanity path, check results > -- > > Key: SLING-11541 > URL: https://issues.apache.org/jira/browse/SLING-11541 > Project: Sling > Issue Type: Improvement > Components: ResourceResolver >Reporter: Julian Reschke >Assignee: Carsten Ziegeler >Priority: Minor > Fix For: Resource Resolver 1.11.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > This is another step towards the goal of using paged queries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11742) Provide alternative equitable terminology for properties
[ https://issues.apache.org/jira/browse/SLING-11742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-11742. -- > Provide alternative equitable terminology for properties > > > Key: SLING-11742 > URL: https://issues.apache.org/jira/browse/SLING-11742 > Project: Sling > Issue Type: Improvement >Reporter: Cioriia Cristian >Assignee: Cioriia Cristian >Priority: Major > Fix For: Resource Resolver 1.11.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > The "resource.resolver.vanitypath.blacklist" and > "resource.resolver.vanitypath.whitelist" proeprties contain terms which are > considered inequitable terminology and some customers are prevented to use > these terms by their git commit policies. > Therefore, some more acceptable equivalents should be provided for these > terms. The proposal is to provide the > "resource.resolver.vanitypath.deniedlist" and > "resource.resolver.vanitypath.allowedlist" alternatives for them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11835) resource resolver: should not use SNAPSHOT version of API
[ https://issues.apache.org/jira/browse/SLING-11835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-11835. -- > resource resolver: should not use SNAPSHOT version of API > - > > Key: SLING-11835 > URL: https://issues.apache.org/jira/browse/SLING-11835 > Project: Sling > Issue Type: Task > Components: ResourceResolver >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: Resource Resolver 1.11.0 > > > Introduced during the last release > (https://github.com/apache/sling-org-apache-sling-resourceresolver/commit/0fa68503b788bd016a9e87ab8dcf406848e0ea07) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12017) resource resolver: add fallback when paged query fails due to missing index
[ https://issues.apache.org/jira/browse/SLING-12017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-12017. -- > resource resolver: add fallback when paged query fails due to missing index > --- > > Key: SLING-12017 > URL: https://issues.apache.org/jira/browse/SLING-12017 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: Resource Resolver 1.11.0 > > > When the underlying repo supports the "first" operator, but the appropiate > index is missing, the query might fail with an UnspportedOperationException, > even though it might have suceeded without paging. > Therefore, catch that exception and fallback to simple query. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11593) Clarify behaviour of "Vanity Path Precedence" flag for the resource resolver factory
[
https://issues.apache.org/jira/browse/SLING-11593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding closed SLING-11593.
--
> Clarify behaviour of "Vanity Path Precedence" flag for the resource resolver
> factory
>
>
> Key: SLING-11593
> URL: https://issues.apache.org/jira/browse/SLING-11593
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: Resource Resolver 1.11.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The "Vanity Path Precedence" flag is currently described as {quote}This flag
> controls whether vanity paths will have precedence over existing /etc/map
> mapping{quote}.
> We should clarify that this flag influences only the resolution process, not
> mapping selection.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-11757) resource resolver: pathless URL in vanity path causes NPE in ResourceMapperImpl.apply()
[
https://issues.apache.org/jira/browse/SLING-11757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding closed SLING-11757.
--
> resource resolver: pathless URL in vanity path causes NPE in
> ResourceMapperImpl.apply()
> ---
>
> Key: SLING-11757
> URL: https://issues.apache.org/jira/browse/SLING-11757
> Project: Sling
> Issue Type: Sub-task
> Components: ResourceResolver
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: Resource Resolver 1.11.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {noformat}
> java.lang.NullPointerException
> at java.lang.String.concat(String.java:2027)
> at
> org.apache.sling.resourceresolver.impl.mapping.ResourceMapperImpl$ApplyContextPath.apply(ResourceMapperImpl.java:371)
> at
> org.apache.sling.resourceresolver.impl.mapping.ResourceMapperImpl$ApplyContextPath.apply(ResourceMapperImpl.java:345)
> at java.util.ArrayList.replaceAll(ArrayList.java:1452)
> at
> org.apache.sling.resourceresolver.impl.mapping.ResourceMapperImpl.getAllMappings(ResourceMapperImpl.java:171)
> at
> org.apache.sling.resourceresolver.impl.mapping.ResourceMapperImpl.getMapping(ResourceMapperImpl.java:73)
> at
> org.apache.sling.resourceresolver.impl.mapping.ResourceMapperImplTest$ExpectedMappings.verify(ResourceMapperImplTest.java:510)
> at
> org.apache.sling.resourceresolver.impl.mapping.ResourceMapperImplTest.mapResourceWithVanityPathsURLTargetNoPath(ResourceMapperImplTest.java:402)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SLING-12018) resource resolver: add metrics for resources with sling:alias/vanityPath found on startup
[ https://issues.apache.org/jira/browse/SLING-12018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-12018. -- > resource resolver: add metrics for resources with sling:alias/vanityPath > found on startup > - > > Key: SLING-12018 > URL: https://issues.apache.org/jira/browse/SLING-12018 > Project: Sling > Issue Type: New Feature > Components: ResourceResolver >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: Resource Resolver 1.11.0 > > > ...because the data model on the resources is not the same as in the caches, > so we want to know the actual numbers as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12019) Avoid duplicate ResourceResolverFactory registrations
[ https://issues.apache.org/jira/browse/SLING-12019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-12019. -- > Avoid duplicate ResourceResolverFactory registrations > - > > Key: SLING-12019 > URL: https://issues.apache.org/jira/browse/SLING-12019 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Affects Versions: Resource Resolver 1.10.0 >Reporter: Carsten Ziegeler >Assignee: Julian Sedding >Priority: Critical > Fix For: Resource Resolver 1.11.0 > > > It seems that in some situations a new resource resolver factory is > registered without unregistering the old one - which leads to two factories > being registered. As not all components do eager service binding, these > components stick to the old factory - and the old factory in turn is > basically "empty" meaning all resource providers are unregistered. This > prevents those components from reaching any resource, although everything > looks fine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11755) resource resolver: add test coverage for URL patterns in vanity paths
[ https://issues.apache.org/jira/browse/SLING-11755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-11755. -- > resource resolver: add test coverage for URL patterns in vanity paths > - > > Key: SLING-11755 > URL: https://issues.apache.org/jira/browse/SLING-11755 > Project: Sling > Issue Type: Sub-task > Components: ResourceResolver >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: Resource Resolver 1.11.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11581) use keyset pagination for vanity path query
[ https://issues.apache.org/jira/browse/SLING-11581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-11581. -- > use keyset pagination for vanity path query > --- > > Key: SLING-11581 > URL: https://issues.apache.org/jira/browse/SLING-11581 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Reporter: Julian Reschke >Priority: Major > Fix For: Resource Resolver 1.11.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-11604) Async VanityPathInitializer should log when completed
[ https://issues.apache.org/jira/browse/SLING-11604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-11604. -- > Async VanityPathInitializer should log when completed > - > > Key: SLING-11604 > URL: https://issues.apache.org/jira/browse/SLING-11604 > Project: Sling > Issue Type: Improvement > Components: ResourceResolver >Affects Versions: Resource Resolver 1.10.0 >Reporter: Joerg Hoh >Assignee: Carsten Ziegeler >Priority: Major > Fix For: Resource Resolver 1.11.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > In case the vanity paths are loaded asynchronously, the current > implementation writes a debug statement on completion which contains some > metrics. > It would be good if the loglevel is changed to INFO, because the information > of completion can be useful to understand that the vanity paths are now fully > available. > Also it would be good to have the total time of this thread being logged. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12021) Update to Parent 52
[ https://issues.apache.org/jira/browse/SLING-12021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-12021. -- > Update to Parent 52 > --- > > Key: SLING-12021 > URL: https://issues.apache.org/jira/browse/SLING-12021 > Project: Sling > Issue Type: Task > Components: ResourceResolver >Affects Versions: Resource Resolver 1.10.0 >Reporter: Joerg Hoh >Assignee: Joerg Hoh >Priority: Major > Fix For: Resource Resolver 1.11.0 > > > Right now the ResourceResolver does not build on Java 17. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11511) Allow checking the map/resolve result for an empty path
[ https://issues.apache.org/jira/browse/SLING-11511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-11511: --- Fix Version/s: Resource Resolver 1.11.2 (was: Resource Resolver 1.11.0) > Allow checking the map/resolve result for an empty path > --- > > Key: SLING-11511 > URL: https://issues.apache.org/jira/browse/SLING-11511 > Project: Sling > Issue Type: Improvement > Components: ResourceResolver >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Resource Resolver 1.11.2 > > > The resource resolver API supports mapping/resolving empty paths, although > this is an invalid path. > The web console plug-in should support this as well, to better support > debugging for scenarios like SLING-10844 . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11513) Allow impersonating an user when checking the result of a map/resolve call
[ https://issues.apache.org/jira/browse/SLING-11513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated SLING-11513: --- Fix Version/s: Resource Resolver 1.11.2 (was: Resource Resolver 1.11.0) > Allow impersonating an user when checking the result of a map/resolve call > -- > > Key: SLING-11513 > URL: https://issues.apache.org/jira/browse/SLING-11513 > Project: Sling > Issue Type: Improvement > Components: ResourceResolver >Reporter: Robert Munteanu >Assignee: Robert Munteanu >Priority: Major > Fix For: Resource Resolver 1.11.2 > > Attachments: screenshot-1.png > > > When debugging various resolve/map issues ( e.g. SLING-10844 ) it is useful > to be able to impersonate a user that does not have access to the web console. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12019) Avoid duplicate ResourceResolverFactory registrations
[ https://issues.apache.org/jira/browse/SLING-12019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding resolved SLING-12019. Resolution: Fixed > Avoid duplicate ResourceResolverFactory registrations > - > > Key: SLING-12019 > URL: https://issues.apache.org/jira/browse/SLING-12019 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Affects Versions: Resource Resolver 1.10.0 >Reporter: Carsten Ziegeler >Assignee: Julian Sedding >Priority: Critical > Fix For: Resource Resolver 1.11.0 > > > It seems that in some situations a new resource resolver factory is > registered without unregistering the old one - which leads to two factories > being registered. As not all components do eager service binding, these > components stick to the old factory - and the old factory in turn is > basically "empty" meaning all resource providers are unregistered. This > prevents those components from reaching any resource, although everything > looks fine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12019) Avoid duplicate ResourceResolverFactory registrations
[ https://issues.apache.org/jira/browse/SLING-12019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766367#comment-17766367 ] Julian Sedding commented on SLING-12019: Merged [PR #104|https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/104]. > Avoid duplicate ResourceResolverFactory registrations > - > > Key: SLING-12019 > URL: https://issues.apache.org/jira/browse/SLING-12019 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Affects Versions: Resource Resolver 1.10.0 >Reporter: Carsten Ziegeler >Assignee: Julian Sedding >Priority: Critical > Fix For: Resource Resolver 1.11.0 > > > It seems that in some situations a new resource resolver factory is > registered without unregistering the old one - which leads to two factories > being registered. As not all components do eager service binding, these > components stick to the old factory - and the old factory in turn is > basically "empty" meaning all resource providers are unregistered. This > prevents those components from reaching any resource, although everything > looks fine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SLING-12019) Avoid duplicate ResourceResolverFactory registrations
[ https://issues.apache.org/jira/browse/SLING-12019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764694#comment-17764694 ] Julian Sedding edited comment on SLING-12019 at 9/18/23 12:39 PM: -- Merged [PR #100|https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/100]. was (Author: jsedding): Merged PR. > Avoid duplicate ResourceResolverFactory registrations > - > > Key: SLING-12019 > URL: https://issues.apache.org/jira/browse/SLING-12019 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Affects Versions: Resource Resolver 1.10.0 >Reporter: Carsten Ziegeler >Assignee: Julian Sedding >Priority: Critical > Fix For: Resource Resolver 1.11.0 > > > It seems that in some situations a new resource resolver factory is > registered without unregistering the old one - which leads to two factories > being registered. As not all components do eager service binding, these > components stick to the old factory - and the old factory in turn is > basically "empty" meaning all resource providers are unregistered. This > prevents those components from reaching any resource, although everything > looks fine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (SLING-12019) Avoid duplicate ResourceResolverFactory registrations
[
https://issues.apache.org/jira/browse/SLING-12019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding reopened SLING-12019:
I discovered an issue with the fix, affecting reconfiguration of
{{ResourceResolverFactoryActivator}} via its {{modified()}} method. It can lead
to no RRF being registered.
> Avoid duplicate ResourceResolverFactory registrations
> -
>
> Key: SLING-12019
> URL: https://issues.apache.org/jira/browse/SLING-12019
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
>Affects Versions: Resource Resolver 1.10.0
>Reporter: Carsten Ziegeler
>Assignee: Julian Sedding
>Priority: Critical
> Fix For: Resource Resolver 1.11.0
>
>
> It seems that in some situations a new resource resolver factory is
> registered without unregistering the old one - which leads to two factories
> being registered. As not all components do eager service binding, these
> components stick to the old factory - and the old factory in turn is
> basically "empty" meaning all resource providers are unregistered. This
> prevents those components from reaching any resource, although everything
> looks fine.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12019) Avoid duplicate ResourceResolverFactory registrations
[ https://issues.apache.org/jira/browse/SLING-12019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding resolved SLING-12019. Resolution: Fixed Merged PR. > Avoid duplicate ResourceResolverFactory registrations > - > > Key: SLING-12019 > URL: https://issues.apache.org/jira/browse/SLING-12019 > Project: Sling > Issue Type: Bug > Components: ResourceResolver >Affects Versions: Resource Resolver 1.10.0 >Reporter: Carsten Ziegeler >Assignee: Julian Sedding >Priority: Critical > Fix For: Resource Resolver 1.11.0 > > > It seems that in some situations a new resource resolver factory is > registered without unregistering the old one - which leads to two factories > being registered. As not all components do eager service binding, these > components stick to the old factory - and the old factory in turn is > basically "empty" meaning all resource providers are unregistered. This > prevents those components from reaching any resource, although everything > looks fine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-11919) [osgi-mock] Support R8 field injection of type Optional
[
https://issues.apache.org/jira/browse/SLING-11919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding resolved SLING-11919.
Fix Version/s: Testing OSGi Mock 3.3.10
Resolution: Fixed
> [osgi-mock] Support R8 field injection of type Optional
> ---
>
> Key: SLING-11919
> URL: https://issues.apache.org/jira/browse/SLING-11919
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.3.8
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: Testing OSGi Mock 3.3.10
>
>
> The OSGi R8 Declarative Services specification allows a component's field of
> type {{Optional}} to be annotated with {{@Reference}}. In this case the
> cardinality defaults to {{OPTIONAL}} and depending on the presence of the
> service an empty {{Optional}}, or an {{Optional}} holding the service, is
> injected.
> Injecting fields of type {{Optional}} should be supported in {{osgi-mock}}.
> See also
> https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.component.html#service.component-field.injection
> cc [~sseifert]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-11919) [osgi-mock] Support R8 field injection of type Optional
Julian Sedding created SLING-11919:
--
Summary: [osgi-mock] Support R8 field injection of type Optional
Key: SLING-11919
URL: https://issues.apache.org/jira/browse/SLING-11919
Project: Sling
Issue Type: Improvement
Components: Testing
Affects Versions: Testing OSGi Mock 3.3.8
Reporter: Julian Sedding
Assignee: Julian Sedding
The OSGi R8 Declarative Services specification allows a component's field of
type {{Optional}} to be annotated with {{@Reference}}. In this case the
cardinality defaults to {{OPTIONAL}} and depending on the presence of the
service an empty {{Optional}}, or an {{Optional}} holding the service, is
injected.
Injecting fields of type {{Optional}} should be supported in {{osgi-mock}}.
See also
https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.component.html#service.component-field.injection
cc [~sseifert]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-8047) Rendered/exported JSON requested via SlingRequestProcessor is not written to output stream
[
https://issues.apache.org/jira/browse/SLING-8047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding resolved SLING-8047.
---
Resolution: Won't Fix
We can always reopen if it turns out to still be an issue.
> Rendered/exported JSON requested via SlingRequestProcessor is not written to
> output stream
> --
>
> Key: SLING-8047
> URL: https://issues.apache.org/jira/browse/SLING-8047
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Reporter: Philip Mundt
>Assignee: Jason E Bailey
>Priority: Major
> Attachments:
> SLING-8047-DefaultGetServlet-does-not-write-to-output-stream.patch,
> SLING-8047-ExportServlet-does-not-write-to-output-stream.patch
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> While trying to facilitate the {{SlingRequestProcessor}} to get a rendered or
> exported JSON representation of a resource, we ran into the problem of the
> response always being empty. The HTML rendering worked without any issue.
> (See example code of [Get the rendered HTML for an AEM resource, component or
> page|http://www.nateyolles.com/blog/2015/10/get-rendered-html-for-an-aem-resource-or-component]
> or [https://stackoverflow.com/a/34218708])
> Main, observed difference seem to be the method calls to print writer:
> h4. JsonRenderer
> {{org.apache.sling.servlets.get.impl.helpers.JsonRenderer#render}} uses
> {{#write}} method of response's print writer.
> h4. ExportServlet (via JacksonExporter)
> {{org.apache.sling.models.impl.ExportServlet#doGet}} uses {{#write}} method
> of response's print writer.
> h4. HTMLRenderer
> {{org.apache.sling.servlets.get.impl.helpers.HtmlRenderer#render}} uses
> {{#print}} and {{#println}} methods of response's print writer.
> h3. Further observations
> When the print writer's {{autoFlush}} property is set to true and one uses
> the {{#println}} method instead of {{#write}}, the {{JsonRenderer}} will
> flush the print writer's buffer to the output stream. Due to wrapping the
> response in
> {{org.apache.sling.scripting.core.impl.helper.OnDemandWriterResponse}} (where
> {{autoFlush=false}}) this does not work for the {{ExportServlet}}.
> When adding implicit {{#flush()}} calls to both classes, both request
> scenarios will work. According to the servlet specification, it should not be
> necessary to flush the print writer, as the container must immediately flush
> all remaining content to the client upon "termination of the service method
> of the servlet".
> Please find two test cases for (where implicit {{#flush()}} calls were added):
> * JsonRenderer ({{sling-org-apache-sling-servlets-get}}):
> [^SLING-8047-DefaultGetServlet-does-not-write-to-output-stream.patch]
> * ExportServlet ({{sling-org-apache-sling-models-impl}}):
> [^SLING-8047-ExportServlet-does-not-write-to-output-stream.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-11824) Deadlock during repository restart
[
https://issues.apache.org/jira/browse/SLING-11824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-11824:
---
Description:
A deadlock can occur when the repository is restarted in a running system. This
may be due to a configuration change of a low level component, but has also
been reported to occur after refreshing the commons-io bundle.
>From the thread dump
{noformat}
"VM Thread" os_prio=0 cpu=106005.20ms elapsed=72363.91s tid=0x56165220f800
nid=0x19ef runnable
"ParGC Thread#0" os_prio=0 cpu=11616.68ms elapsed=72363.93s
tid=0x5616520cb800 nid=0x19ee runnable
"ParGC Thread#1" os_prio=0 cpu=11624.23ms elapsed=72362.83s
tid=0x5616534fd800 nid=0x19f8 runnable
"ParGC Thread#2" os_prio=0 cpu=11621.66ms elapsed=72362.83s
tid=0x561653518000 nid=0x19f9 runnable
"VM Periodic Task Thread" os_prio=0 cpu=32588.40ms elapsed=72360.26s
tid=0x561655593800 nid=0x1a13 waiting on condition
JNI global refs: 98, weak refs: 3
Found one Java-level deadlock:
=
"CM Event Dispatcher (Fire ConfigurationEvent:
pid=org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl)":
waiting to lock monitor 0x56166302ce80 (object 0x0007679e6638, a
org.apache.sling.engine.impl.helper.SlingServletContext),
which is held by "SlingServletContext registration"
"SlingServletContext registration":
waiting to lock monitor 0x5616631e3480 (object 0x00074f987900, a
java.util.HashMap),
which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
pid=org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl)
{noformat}
was:
A deadlock can occur when the repository is restarted in a running system. This
may be due to a configuration change of a low level component, but has also
been reported to occur after stopping and restarting the commons-io bundle.
>From the thread dump
{noformat}
"VM Thread" os_prio=0 cpu=106005.20ms elapsed=72363.91s tid=0x56165220f800
nid=0x19ef runnable
"ParGC Thread#0" os_prio=0 cpu=11616.68ms elapsed=72363.93s
tid=0x5616520cb800 nid=0x19ee runnable
"ParGC Thread#1" os_prio=0 cpu=11624.23ms elapsed=72362.83s
tid=0x5616534fd800 nid=0x19f8 runnable
"ParGC Thread#2" os_prio=0 cpu=11621.66ms elapsed=72362.83s
tid=0x561653518000 nid=0x19f9 runnable
"VM Periodic Task Thread" os_prio=0 cpu=32588.40ms elapsed=72360.26s
tid=0x561655593800 nid=0x1a13 waiting on condition
JNI global refs: 98, weak refs: 3
Found one Java-level deadlock:
=
"CM Event Dispatcher (Fire ConfigurationEvent:
pid=org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl)":
waiting to lock monitor 0x56166302ce80 (object 0x0007679e6638, a
org.apache.sling.engine.impl.helper.SlingServletContext),
which is held by "SlingServletContext registration"
"SlingServletContext registration":
waiting to lock monitor 0x5616631e3480 (object 0x00074f987900, a
java.util.HashMap),
which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
pid=org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl)
{noformat}
> Deadlock during repository restart
> --
>
> Key: SLING-11824
> URL: https://issues.apache.org/jira/browse/SLING-11824
> Project: Sling
> Issue Type: Bug
> Components: Engine
>Affects Versions: Engine 2.14.0
>Reporter: Julian Sedding
>Priority: Major
> Fix For: Engine 2.14.2
>
>
> A deadlock can occur when the repository is restarted in a running system.
> This may be due to a configuration change of a low level component, but has
> also been reported to occur after refreshing the commons-io bundle.
> From the thread dump
> {noformat}
> "VM Thread" os_prio=0 cpu=106005.20ms elapsed=72363.91s
> tid=0x56165220f800 nid=0x19ef runnable
> "ParGC Thread#0" os_prio=0 cpu=11616.68ms elapsed=72363.93s
> tid=0x5616520cb800 nid=0x19ee runnable
> "ParGC Thread#1" os_prio=0 cpu=11624.23ms elapsed=72362.83s
> tid=0x5616534fd800 nid=0x19f8 runnable
> "ParGC Thread#2" os_prio=0 cpu=11621.66ms elapsed=72362.83s
> tid=0x561653518000 nid=0x19f9 runnable
> "VM Periodic Task Thread" os_prio=0 cpu=32588.40ms elapsed=72360.26s
> tid=0x561655593800 nid=0x1a13 waiting on condition
> JNI global refs: 98, weak refs: 3
> Found one Java-level deadlock:
> =
> "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl)":
> waiting to lock monitor 0x56166302ce80 (object 0x0007679e6638, a
> org.apache.sling.engine.impl.helper.SlingServletContext),
> which is held by "SlingServletContext registration"
> "SlingServletContext registration":
> waiting to lock monitor 0x5616631e3480 (object
[jira] [Created] (SLING-11824) Deadlock during repository restart
Julian Sedding created SLING-11824:
--
Summary: Deadlock during repository restart
Key: SLING-11824
URL: https://issues.apache.org/jira/browse/SLING-11824
Project: Sling
Issue Type: Bug
Components: Engine, ResourceResolver
Affects Versions: Engine 2.14.0, Resource Resolver 1.10.0
Reporter: Julian Sedding
Assignee: Carsten Ziegeler
A deadlock can occur when the repository is restarted in a running system. This
may be due to a configuration change of a low level component, but has also
been reported to occur after stopping and restarting the commons-io bundle.
>From the thread dump
{noformat}
"VM Thread" os_prio=0 cpu=106005.20ms elapsed=72363.91s tid=0x56165220f800
nid=0x19ef runnable
"ParGC Thread#0" os_prio=0 cpu=11616.68ms elapsed=72363.93s
tid=0x5616520cb800 nid=0x19ee runnable
"ParGC Thread#1" os_prio=0 cpu=11624.23ms elapsed=72362.83s
tid=0x5616534fd800 nid=0x19f8 runnable
"ParGC Thread#2" os_prio=0 cpu=11621.66ms elapsed=72362.83s
tid=0x561653518000 nid=0x19f9 runnable
"VM Periodic Task Thread" os_prio=0 cpu=32588.40ms elapsed=72360.26s
tid=0x561655593800 nid=0x1a13 waiting on condition
JNI global refs: 98, weak refs: 3
Found one Java-level deadlock:
=
"CM Event Dispatcher (Fire ConfigurationEvent:
pid=org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl)":
waiting to lock monitor 0x56166302ce80 (object 0x0007679e6638, a
org.apache.sling.engine.impl.helper.SlingServletContext),
which is held by "SlingServletContext registration"
"SlingServletContext registration":
waiting to lock monitor 0x5616631e3480 (object 0x00074f987900, a
java.util.HashMap),
which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
pid=org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-10900) Update graphql-java to version 17
[
https://issues.apache.org/jira/browse/SLING-10900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-10900:
---
Summary: Update graphql-java to version 17 (was: Update graphl-java to
version 17)
> Update graphql-java to version 17
> -
>
> Key: SLING-10900
> URL: https://issues.apache.org/jira/browse/SLING-10900
> Project: Sling
> Issue Type: Improvement
> Components: GraphQL
>Reporter: Radu Cotescu
>Assignee: Andreas Schaefer
>Priority: Major
> Fix For: GraphQL Core 0.0.18
>
>
> {{graphql-java}} 17 brings a set of performance improvements [0] which could
> benefit the GraphQL Core bundle:
> * [2067|https://github.com/graphql-java/graphql-java/pull/2067] Support for
> Streams and Iterators
> * Dramatic performance improvements in GraphQLSchema building
> * Dramatic performance improvements in DataFetchingFieldSelectionSet
> * Dramatic performance improvements in large query validation
> [0] - https://github.com/graphql-java/graphql-java/releases/tag/v17.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-11483) NodePropertiesVisitor causing session writes on set properties without changed properties
[ https://issues.apache.org/jira/browse/SLING-11483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17573643#comment-17573643 ] Julian Sedding commented on SLING-11483: Fixed with [PR #35|https://github.com/apache/sling-org-apache-sling-jcr-repoinit/pull/35]. cc [~dsuess] > NodePropertiesVisitor causing session writes on set properties without > changed properties > - > > Key: SLING-11483 > URL: https://issues.apache.org/jira/browse/SLING-11483 > Project: Sling > Issue Type: Bug > Components: Repoinit >Affects Versions: Repoinit JCR 1.1.40 >Reporter: Dominik Süß >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Executing Repoinit twice without contradicting statements should cause no > writes, so the session returned by the visitors should return false for > session.hasPendingChanges() > The way the NodePropertiesVisitor is implemented the properties are always > written if this is no defaults statement. While this satisfies the contract > that for "default" there should be no writes in case properties are already > present it does even cause a write in case there are no changes what so > ever. The behavior of JCR is that in case the same properties are written > this is equivalent to a touch (and would likely update the last modified > field, although not verified) Adding a comparison for the set scenario to > avoid writting properties if the target state already matches the definition > eliminates the false change indicator. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-11189) Content Loader: Race condition registering readers vs. loading content
[
https://issues.apache.org/jira/browse/SLING-11189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503662#comment-17503662
]
Julian Sedding commented on SLING-11189:
[~sseifert] in case you had tried my suggestion: sorry, I had gotten the
property name of {{\*.cardinality.minimum}} wrong (edited now in my comment to
avoid misleading anyone).
> Content Loader: Race condition registering readers vs. loading content
> --
>
> Key: SLING-11189
> URL: https://issues.apache.org/jira/browse/SLING-11189
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: JCR ContentLoader 2.5.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: JCR ContentLoader 2.5.2
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> in SLING-11168 we detected a specific problem with Composum in Sling Starter
> 12, which only occured on Windows 10 environments (and even there not
> consistently in every scenario).
> it seems that it may happen that Sling-Initial-Content is loaded from the
> bundles when the ContentReader implementations are not yet registered on the
> ContentReaderWhiteboard.
> when this happens, the content is loaded into the repository, but files like
> *.json are not transformed to nodes and properties, but is stored as binary
> json files in the repository.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-11168) Sling Starter 12: Unable to launch Composum
[
https://issues.apache.org/jira/browse/SLING-11168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503659#comment-17503659
]
Julian Sedding commented on SLING-11168:
I created [PR
#59|https://github.com/apache/sling-org-apache-sling-starter/pull/59] with a
trimmed down version of my [suggestion in
SLING-11189|https://issues.apache.org/jira/browse/SLING-11189?focusedCommentId=17502951=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17502951].
I only set the minimum cardinality to 4 instead of also enforcing
"component.name" properties to match the ootb readers. Enforcing the
"component.name" properties would prevent any external {{ContentReader}}
services from binding. That should be "good enough" for now.
> Sling Starter 12: Unable to launch Composum
> ---
>
> Key: SLING-11168
> URL: https://issues.apache.org/jira/browse/SLING-11168
> Project: Sling
> Issue Type: Bug
> Components: Starter
>Affects Versions: Starter 12
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: Starter 12
>
> Attachments: error.log, image-2022-03-01-17-47-08-965.png,
> screenshot-1.png, starter-12-windows.log
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> environment:
> * Windows 10
> * java 11.0.13 2021-10-19 LTS
> * Sling Starter: https://github.com/apache/sling-org-apache-sling-starter
> started sling starter 12 (or actually 13-SNAPSHOT from current master branch)
> with:
> {noformat}
> mvn clean install
> java -jar target/dependency/org.apache.sling.feature.launcher.jar -f
> target/slingfeature-tmp/feature-oak_tar.json
> {noformat}
> when trying to access composum via http://localhost:8080/bin/browser.html i
> get the normal sling login (if not logged in already) and login as
> admin/admin.
> directly after this i see a blink of composum, which is replaced immediately
> with another composum login dialog:
> [^image-2022-03-01-17-47-08-965.png]
> [^error.log] from the instance
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (SLING-11189) Content Loader: Race condition registering readers vs. loading content
[
https://issues.apache.org/jira/browse/SLING-11189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502951#comment-17502951
]
Julian Sedding edited comment on SLING-11189 at 3/9/22, 3:17 PM:
-
Purely with DS and OSGi R7, I think it could be done with a combination of the
{{\*.target}} and the {{\*.cardinality.minimum}} [reference
properties|http://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.component.html#service.component-reference.properties].
The {{contentReader.target}} reference property would need to OR together a
list of {{component.name}} properties, i.e.
{{{}(|(component.name=org.apache.sling.jcr.contentloader.internal.readers.JsonReader)(component.name=org.apache.sling.jcr.contentloader.internal.readers.OrderedJsonReader)(component.name=org.apache.sling.jcr.contentloader.internal.readers.XmlReader)(component.name=org.apache.sling.jcr.contentloader.internal.readers.ZipReader)){}}}.
And the {{contentReader.cardinality.minimum}} property would need to be set to
the number of readers, i.e. 4 in this case.
Unless I am missing something, this should work. WDYT?
was (Author: jsedding):
Purely with DS and OSGi R7, I think it could be done with a combination of the
{{\*.target}} and the {{\*.minimum.cardinality}} [reference
properties|http://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.component.html#service.component-reference.properties].
The {{contentReader.target}} reference property would need to OR together a
list of {{component.name}} properties, i.e.
{{{}(|(component.name=org.apache.sling.jcr.contentloader.internal.readers.JsonReader)(component.name=org.apache.sling.jcr.contentloader.internal.readers.OrderedJsonReader)(component.name=org.apache.sling.jcr.contentloader.internal.readers.XmlReader)(component.name=org.apache.sling.jcr.contentloader.internal.readers.ZipReader)){}}}.
And the {{contentReader.minimum.cardinality}} property would need to be set to
the number of readers, i.e. 4 in this case.
Unless I am missing something, this should work. WDYT?
> Content Loader: Race condition registering readers vs. loading content
> --
>
> Key: SLING-11189
> URL: https://issues.apache.org/jira/browse/SLING-11189
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: JCR ContentLoader 2.5.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: JCR ContentLoader 2.5.2
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> in SLING-11168 we detected a specific problem with Composum in Sling Starter
> 12, which only occured on Windows 10 environments (and even there not
> consistently in every scenario).
> it seems that it may happen that Sling-Initial-Content is loaded from the
> bundles when the ContentReader implementations are not yet registered on the
> ContentReaderWhiteboard.
> when this happens, the content is loaded into the repository, but files like
> *.json are not transformed to nodes and properties, but is stored as binary
> json files in the repository.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (SLING-11189) Content Loader: Race condition registering readers vs. loading content
[
https://issues.apache.org/jira/browse/SLING-11189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502951#comment-17502951
]
Julian Sedding edited comment on SLING-11189 at 3/9/22, 3:01 PM:
-
Purely with DS and OSGi R7, I think it could be done with a combination of the
{{\*.target}} and the {{\*.minimum.cardinality}} [reference
properties|http://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.component.html#service.component-reference.properties].
The {{contentReader.target}} reference property would need to OR together a
list of {{component.name}} properties, i.e.
{{{}(|(component.name=org.apache.sling.jcr.contentloader.internal.readers.JsonReader)(component.name=org.apache.sling.jcr.contentloader.internal.readers.OrderedJsonReader)(component.name=org.apache.sling.jcr.contentloader.internal.readers.XmlReader)(component.name=org.apache.sling.jcr.contentloader.internal.readers.ZipReader)){}}}.
And the {{contentReader.minimum.cardinality}} property would need to be set to
the number of readers, i.e. 4 in this case.
Unless I am missing something, this should work. WDYT?
was (Author: jsedding):
Purely with DS and OSGi R7, I think it could be done with a combination of the
{{*.target*}} *and the {{}}*{{.minimum.cardinality}} [reference
properties|http://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.component.html#service.component-reference.properties].
The {{contentReader.target}} reference property would need to OR together a
list of {{component.name}} properties, i.e.
{{{}(|(component.name=org.apache.sling.jcr.contentloader.internal.readers.JsonReader)(component.name=org.apache.sling.jcr.contentloader.internal.readers.OrderedJsonReader)(component.name=org.apache.sling.jcr.contentloader.internal.readers.XmlReader)(component.name=org.apache.sling.jcr.contentloader.internal.readers.ZipReader)){}}}.
And the {{contentReader.minimum.cardinality}} property would need to be set to
the number of readers, i.e. 4 in this case.
Unless I am missing something, this should work. WDYT?
> Content Loader: Race condition registering readers vs. loading content
> --
>
> Key: SLING-11189
> URL: https://issues.apache.org/jira/browse/SLING-11189
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: JCR ContentLoader 2.5.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Major
> Fix For: JCR ContentLoader 2.5.2
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> in SLING-11168 we detected a specific problem with Composum in Sling Starter
> 12, which only occured on Windows 10 environments (and even there not
> consistently in every scenario).
> it seems that it may happen that Sling-Initial-Content is loaded from the
> bundles when the ContentReader implementations are not yet registered on the
> ContentReaderWhiteboard.
> when this happens, the content is loaded into the repository, but files like
> *.json are not transformed to nodes and properties, but is stored as binary
> json files in the repository.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-11189) Content Loader: Race condition registering readers vs. loading content
[
https://issues.apache.org/jira/browse/SLING-11189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502951#comment-17502951
]
Julian Sedding commented on SLING-11189:
Purely with DS and OSGi R7, I think it could be done with a combination of the
{{*.target*}} *and the {{}}*{{.minimum.cardinality}} [reference
properties|http://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.component.html#service.component-reference.properties].
The {{contentReader.target}} reference property would need to OR together a
list of {{component.name}} properties, i.e.
{{{}(|(component.name=org.apache.sling.jcr.contentloader.internal.readers.JsonReader)(component.name=org.apache.sling.jcr.contentloader.internal.readers.OrderedJsonReader)(component.name=org.apache.sling.jcr.contentloader.internal.readers.XmlReader)(component.name=org.apache.sling.jcr.contentloader.internal.readers.ZipReader)){}}}.
And the {{contentReader.minimum.cardinality}} property would need to be set to
the number of readers, i.e. 4 in this case.
Unless I am missing something, this should work. WDYT?
> Content Loader: Race condition registering readers vs. loading content
> --
>
> Key: SLING-11189
> URL: https://issues.apache.org/jira/browse/SLING-11189
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: JCR ContentLoader 2.5.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Major
>
> in SLING-11168 we detected a specific problem with Composum in Sling Starter
> 12, which only occured on Windows 10 environments (and even there not
> consistently in every scenario).
> it seems that it may happen that Sling-Initial-Content is loaded from the
> bundles when the ContentReader implementations are not yet registered on the
> ContentReaderWhiteboard.
> when this happens, the content is loaded into the repository, but files like
> *.json are not transformed to nodes and properties, but is stored as binary
> json files in the repository.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SLING-7813) SlingHttpServletResponseImpl should log when setStatus is called after it is committed
[
https://issues.apache.org/jira/browse/SLING-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17415128#comment-17415128
]
Julian Sedding commented on SLING-7813:
---
[~bdelacretaz] just for the record. The commit you linked does not change the
behaviour. After the logging {{#setStatus()}} always delegates back to
{{super}} (maybe you didn't notice the end of the if-statement checking for
{{isCommitted()}}?). It could be argued that delegating
{{#setStatus(statusCode, null)}} to {{#setStatus(statusCode)}} is a behavioural
change, but that should be very subtle and we could improve this if desired.
> SlingHttpServletResponseImpl should log when setStatus is called after it is
> committed
> --
>
> Key: SLING-7813
> URL: https://issues.apache.org/jira/browse/SLING-7813
> Project: Sling
> Issue Type: Improvement
> Components: Engine
>Affects Versions: Engine 2.6.12
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: Engine 2.6.14
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I have been debugging a scenario, where a response did not have the (in this
> case) expected status code {{500}} set by an error handling script, but
> instead the status code was {{200}}.
> It turns out that a rendering script calls {{#flushBuffer()}} on the response
> early on in order to optimize user experience. Later in the rendering chain a
> JSP causes a {{NullPointerException}}, triggering an error handler which
> calls {{#setStatus(500)}}. The {{#setStatus}} call is silently ignored.
> "Fixing" this problem would require buffering the entire response and
> ignoring any flush calls (be it {{#flushBuffer()}}, {{#getWriter().flush()}}
> or {{#getOutputStream().flush()}}). This would be a change in behaviour, a
> violation of the Servlet spec and performance issues waiting to happen. Thus
> I am ruling out this option.
> However, it would be helpful to improve "debuggability" of the problem. I
> propose to log a warning when {{#setStatus()}} is called. Additionally, if
> debug logging is enabled, I propose to log a stack trace to identify where
> the flush call originated (unless the flush was due to too many bytes
> written, which is not very helpful information).
> cc [~rombert]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-10738) Sling Model inheritance breaks with component exporter
[
https://issues.apache.org/jira/browse/SLING-10738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405697#comment-17405697
]
Julian Sedding edited comment on SLING-10738 at 8/27/21, 9:14 AM:
--
[~cshawaus] I've finally taken the time to check this out. For me it works
flawlessly with {{org.apache.sling.models.impl}} version {{1.4.16}}. Or I am
testing the wrong thing. I am requesting {{/content/demo/us/en.model.json}} and
I get lots of rendered JSON, which includes the property "myCustomProperty".
Note: I did remove your workaround for the tests.
One thing I noticed is that you set the default injection strategy to
"optional". I don't understand why, but in any case you should at least make
the "layoutContainer" field "required" in order to fail early and hopefully get
a meaningful error message in the logs.
If I misunderstood your problem, please advise on how to test with a few simple
bullet points.
was (Author: jsedding):
[~cshawaus] I've finally taken the time to check this out. For me it works
flawlessly, or I am testing the wrong thing. I am requesting
{{/content/demo/us/en.model.json}} and I get lots of rendered JSON, which
includes the property "myCustomProperty". Note: I did remove your workaround
for the tests.
One thing I noticed is that you set the default injection strategy to
"optional". I don't understand why, but in any case you should at least make
the "layoutContainer" field "required" in order to fail early and hopefully get
a meaningful error message in the logs.
If I misunderstood your problem, please advise on how to test with a few simple
bullet points.
> Sling Model inheritance breaks with component exporter
> --
>
> Key: SLING-10738
> URL: https://issues.apache.org/jira/browse/SLING-10738
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Reporter: Chris Shaw
>Priority: Major
>
> Hi,
> I'm currently supporting a project where I need to extend the LayoutContainer
> class in AEM Core Components. Completing this process was easy and
> straightforward when solely dealing solely with Sling Model Delegation.
> Shortly after confirming this behaviour was working correctly, I added
> Adobe's *ContainerExporter.class* to the *@Model* adapters and noticed that
> Sling Model Delegation stopped working.
> I am raising this issue here first because the same method of extending
> models in AEM Core Components works without issue except for the
> LayoutContainer model. Below is the basic code before adding the exporters.
> {code:java}
> @Model(
> adaptables = SlingHttpServletRequest.class,
> adapters = {LayoutContainer.class},
> resourceType = CustomContainerImpl.RESOURCE_TYPE,
> defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL
> )
> public class CustomContainerImpl implements LayoutContainer {
> protected static final String RESOURCE_TYPE =
> "project/components/custom-container";
> @Self
> @Via(type = ResourceSuperType.class)
> private LayoutContainer layoutContainer;
>
> // ... implementation
> }
> {code}
> With this code, no issues at a page level are observed and all inherited
> behaviours work as expected including appending *.model.json* to the page URL.
> Once I move beyond this and apply the exporter adapters, *.model.json* no
> longer works correctly and Sling Model Delegation breaks completely.
> {code:java}
> @Model(
> adaptables = SlingHttpServletRequest.class,
> adapters = {LayoutContainer.class, ComponentExporter.class,
> ContainerExporter.class},
> resourceType = CustomContainerImpl.RESOURCE_TYPE,
> defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL
> )
> public class CustomContainerImpl implements LayoutContainer {
> protected static final String RESOURCE_TYPE =
> "project/components/custom-container";
> @Self
> @Via(type = ResourceSuperType.class)
> private LayoutContainer layoutContainer;
>
> // ... implementation
> }
> {code}
> Note that the adapters are: *ComponentExporter.class* and
> *ContainerExporter.class*.
> What can be observed are 2 key issues:
> # The *layoutContainer* property always returns *null*
> # The previous JSON structure containing *root* elements is always empty for
> child pages
> As a workaround to at least ensure the inheritance works, I have reverted to
> using a *ModelFactory* instance which works from an authoring perspective but
> doesn't solve the JSON output issue.
> {code:java}
> layoutContainer = modelFactory.getModelFromWrappedRequest(
> request,
> request.getResource(),
> LayoutContainer.class);{code}
> It would be great to get insight into this as I was to be 100% sure Sling is
> not to blame before raising an
[jira] [Commented] (SLING-10738) Sling Model inheritance breaks with component exporter
[
https://issues.apache.org/jira/browse/SLING-10738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405697#comment-17405697
]
Julian Sedding commented on SLING-10738:
[~cshawaus] I've finally taken the time to check this out. For me it works
flawlessly, or I am testing the wrong thing. I am requesting
{{/content/demo/us/en.model.json}} and I get lots of rendered JSON, which
includes the property "myCustomProperty". Note: I did remove your workaround
for the tests.
One thing I noticed is that you set the default injection strategy to
"optional". I don't understand why, but in any case you should at least make
the "layoutContainer" field "required" in order to fail early and hopefully get
a meaningful error message in the logs.
If I misunderstood your problem, please advise on how to test with a few simple
bullet points.
> Sling Model inheritance breaks with component exporter
> --
>
> Key: SLING-10738
> URL: https://issues.apache.org/jira/browse/SLING-10738
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Reporter: Chris Shaw
>Priority: Major
>
> Hi,
> I'm currently supporting a project where I need to extend the LayoutContainer
> class in AEM Core Components. Completing this process was easy and
> straightforward when solely dealing solely with Sling Model Delegation.
> Shortly after confirming this behaviour was working correctly, I added
> Adobe's *ContainerExporter.class* to the *@Model* adapters and noticed that
> Sling Model Delegation stopped working.
> I am raising this issue here first because the same method of extending
> models in AEM Core Components works without issue except for the
> LayoutContainer model. Below is the basic code before adding the exporters.
> {code:java}
> @Model(
> adaptables = SlingHttpServletRequest.class,
> adapters = {LayoutContainer.class},
> resourceType = CustomContainerImpl.RESOURCE_TYPE,
> defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL
> )
> public class CustomContainerImpl implements LayoutContainer {
> protected static final String RESOURCE_TYPE =
> "project/components/custom-container";
> @Self
> @Via(type = ResourceSuperType.class)
> private LayoutContainer layoutContainer;
>
> // ... implementation
> }
> {code}
> With this code, no issues at a page level are observed and all inherited
> behaviours work as expected including appending *.model.json* to the page URL.
> Once I move beyond this and apply the exporter adapters, *.model.json* no
> longer works correctly and Sling Model Delegation breaks completely.
> {code:java}
> @Model(
> adaptables = SlingHttpServletRequest.class,
> adapters = {LayoutContainer.class, ComponentExporter.class,
> ContainerExporter.class},
> resourceType = CustomContainerImpl.RESOURCE_TYPE,
> defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL
> )
> public class CustomContainerImpl implements LayoutContainer {
> protected static final String RESOURCE_TYPE =
> "project/components/custom-container";
> @Self
> @Via(type = ResourceSuperType.class)
> private LayoutContainer layoutContainer;
>
> // ... implementation
> }
> {code}
> Note that the adapters are: *ComponentExporter.class* and
> *ContainerExporter.class*.
> What can be observed are 2 key issues:
> # The *layoutContainer* property always returns *null*
> # The previous JSON structure containing *root* elements is always empty for
> child pages
> As a workaround to at least ensure the inheritance works, I have reverted to
> using a *ModelFactory* instance which works from an authoring perspective but
> doesn't solve the JSON output issue.
> {code:java}
> layoutContainer = modelFactory.getModelFromWrappedRequest(
> request,
> request.getResource(),
> LayoutContainer.class);{code}
> It would be great to get insight into this as I was to be 100% sure Sling is
> not to blame before raising an issue with Adobe.
> Thanks for your time!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-10738) Sling Model inheritance breaks with component exporter
[
https://issues.apache.org/jira/browse/SLING-10738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400256#comment-17400256
]
Julian Sedding commented on SLING-10738:
Ok, fair enough. Then I don't see an obvious reason why it would fail. If no
one comes up with a good answer, it may help if you can provide a sample
project to replicate the issue. Especially in the absence of log messages (I
assume you tried debug logging?), that could help a lot with the analysis.
> Sling Model inheritance breaks with component exporter
> --
>
> Key: SLING-10738
> URL: https://issues.apache.org/jira/browse/SLING-10738
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Reporter: Chris Shaw
>Priority: Major
>
> Hi,
> I'm currently supporting a project where I need to extend the LayoutContainer
> class in AEM Core Components. Completing this process was easy and
> straightforward when solely dealing solely with Sling Model Delegation.
> Shortly after confirming this behaviour was working correctly, I added
> Adobe's *ContainerExporter.class* to the *@Model* adapters and noticed that
> Sling Model Delegation stopped working.
> I am raising this issue here first because the same method of extending
> models in AEM Core Components works without issue except for the
> LayoutContainer model. Below is the basic code before adding the exporters.
> {code:java}
> @Model(
> adaptables = SlingHttpServletRequest.class,
> adapters = {LayoutContainer.class},
> resourceType = CustomContainerImpl.RESOURCE_TYPE,
> defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL
> )
> public class CustomContainerImpl implements LayoutContainer {
> protected static final String RESOURCE_TYPE =
> "project/components/custom-container";
> @Self
> @Via(type = ResourceSuperType.class)
> private LayoutContainer layoutContainer;
>
> // ... implementation
> }
> {code}
> With this code, no issues at a page level are observed and all inherited
> behaviours work as expected including appending *.model.json* to the page URL.
> Once I move beyond this and apply the exporter adapters, *.model.json* no
> longer works correctly and Sling Model Delegation breaks completely.
> {code:java}
> @Model(
> adaptables = SlingHttpServletRequest.class,
> adapters = {LayoutContainer.class, ComponentExporter.class,
> ContainerExporter.class},
> resourceType = CustomContainerImpl.RESOURCE_TYPE,
> defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL
> )
> public class CustomContainerImpl implements LayoutContainer {
> protected static final String RESOURCE_TYPE =
> "project/components/custom-container";
> @Self
> @Via(type = ResourceSuperType.class)
> private LayoutContainer layoutContainer;
>
> // ... implementation
> }
> {code}
> Note that the adapters are: *ComponentExporter.class* and
> *ContainerExporter.class*.
> What can be observed are 2 key issues:
> # The *layoutContainer* property always returns *null*
> # The previous JSON structure containing *root* elements is always empty for
> child pages
> As a workaround to at least ensure the inheritance works, I have reverted to
> using a *ModelFactory* instance which works from an authoring perspective but
> doesn't solve the JSON output issue.
> {code:java}
> layoutContainer = modelFactory.getModelFromWrappedRequest(
> request,
> request.getResource(),
> LayoutContainer.class);{code}
> It would be great to get insight into this as I was to be 100% sure Sling is
> not to blame before raising an issue with Adobe.
> Thanks for your time!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-10738) Sling Model inheritance breaks with component exporter
[
https://issues.apache.org/jira/browse/SLING-10738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400242#comment-17400242
]
Julian Sedding commented on SLING-10738:
[~cshawaus] I would assume that your class needs to implement
{{ComponentExporter}} and {{ContainerExporter}} as well as {{LayoutContainer}}
(BTW your current code implements {{LayoutContainer.class}}, that doesn't look
correct. I assume you mean just {{LayoutContainer}}).
I expect that your error.log file may contain further information about what is
happening. My guess would be that you find a {{ClassCastException}} due to the
missing implemented interfaces.
> Sling Model inheritance breaks with component exporter
> --
>
> Key: SLING-10738
> URL: https://issues.apache.org/jira/browse/SLING-10738
> Project: Sling
> Issue Type: Bug
> Components: Sling Models
>Reporter: Chris Shaw
>Priority: Major
>
> Hi,
> I'm currently supporting a project where I need to extend the LayoutContainer
> class in AEM Core Components. Completing this process was easy and
> straightforward when solely dealing solely with Sling Model Delegation.
> Shortly after confirming this behaviour was working correctly, I added
> Adobe's *ContainerExporter.class* to the *@Model* adapters and noticed that
> Sling Model Delegation stopped working.
> I am raising this issue here first because the same method of extending
> models in AEM Core Components works without issue except for the
> LayoutContainer model. Below is the basic code before adding the exporters.
> {code:java}
> @Model(
> adaptables = SlingHttpServletRequest.class,
> adapters = {LayoutContainer.class},
> resourceType = CustomContainerImpl.RESOURCE_TYPE,
> defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL
> )
> public class CustomContainerImpl implements LayoutContainer.class {
> protected static final String RESOURCE_TYPE =
> "project/components/custom-container";
> @Self
> @Via(type = ResourceSuperType.class)
> private LayoutContainer layoutContainer;
>
> // ... implementation
> }
> {code}
> With this code, no issues at a page level are observed and all inherited
> behaviours work as expected including appending *.model.json* to the page URL.
> Once I move beyond this and apply the exporter adapters, *.model.json* no
> longer works correctly and Sling Model Delegation breaks completely.
> {code:java}
> @Model(
> adaptables = SlingHttpServletRequest.class,
> adapters = {LayoutContainer.class, ComponentExporter.class,
> ContainerExporter.class},
> resourceType = CustomContainerImpl.RESOURCE_TYPE,
> defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL
> )
> public class CustomContainerImpl implements LayoutContainer.class {
> protected static final String RESOURCE_TYPE =
> "project/components/custom-container";
> @Self
> @Via(type = ResourceSuperType.class)
> private LayoutContainer layoutContainer;
>
> // ... implementation
> }
> {code}
> Note that the adapters are: *ComponentExporter.class* and
> *ContainerExporter.class*.
> What can be observed are 2 key issues:
> # The *layoutContainer* property always returns *null*
> # The previous JSON structure containing *root* elements is always empty for
> child pages
> As a workaround to at least ensure the inheritance works, I have reverted to
> using a *ModelFactory* instance which works from an authoring perspective but
> doesn't solve the JSON output issue.
> {code:java}
> layoutContainer = modelFactory.getModelFromWrappedRequest(
> request,
> request.getResource(),
> LayoutContainer.class);{code}
> It would be great to get insight into this as I was to be 100% sure Sling is
> not to blame before raising an issue with Adobe.
> Thanks for your time!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-10731) Page cannot be edited after the history has been restored
[
https://issues.apache.org/jira/browse/SLING-10731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17399590#comment-17399590
]
Julian Sedding commented on SLING-10731:
[~dklco] Have you tried with {{:autoCheckout=true}}? I haven't tested it, but
SLING-1573 seems to suggest it should do what your post-op does.
> Page cannot be edited after the history has been restored
> -
>
> Key: SLING-10731
> URL: https://issues.apache.org/jira/browse/SLING-10731
> Project: Sling
> Issue Type: Bug
> Components: App CMS
>Affects Versions: App CMS 1.0.4
>Reporter: James Raynor
>Assignee: Dan Klco
>Priority: Minor
> Fix For: App CMS 1.0.8
>
> Attachments: 1.png
>
>
>
> I recently discovered that the CMS creates a version history and then after
> restoring the history, the page cannot be edited.
> Steps to reproduce:
> 1. Run SlingCMS, go to
> http://localhost:8080/cms/site/content.html/content/apache/sling-apache-org
> 2. Select index and click on "Edit Page".
> 3. Then click on "Manage Versions" in the top right corner of the page, click
> on "Make Versionable", then click on "Manage Versions" in the top right
> corner , click on "Create Version".
> 4. Modify any of the components, e.g. change the text "Apache Sling™ is a
> framework for ..." to "test". to "test" and save it.
> 5. Then click on "Manage Versions" in the top right corner, in Version 1.0,
> click on "Restore Version".
> 6. Then modify any of the components of the page, save it and an error
> appears, it cannot be saved:
> 500
> Server Error
> Forbidden
> You cannot access the requested resource.
> Login?
> After checking the Node browser,
> [http://localhost:8080/bin/browser.html/content/apache/sling-apache-org/index]
> The page "jcr:isCheckedOut" property was found to be false, and after
> changing it to true, the functionality was restored. Perhaps the problem
> needs to be fixed here.
> Other suggestions.
> 1. Click on "Manage Versions" in the top right corner for the first time.
> 2. You need to click on "Make Versionable" first.
> 3. Then you need to open "Manage Versions" again, then the "Create Version"
> button will appear on the page.
> "Make Versionable" should be a redundant step and should be designed to
> create versions directly by clicking on "Create Version".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-10611) PDF file name is garbled
[
https://issues.apache.org/jira/browse/SLING-10611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380432#comment-17380432
]
Julian Sedding edited comment on SLING-10611 at 7/14/21, 8:27 AM:
--
You can send a parameter {{\_charset\_=utf-8}} when you upload the files. That
should have the same effect as adjusting the default parameter encoding. I
can't remember at the moment why the default parameter encoding is not set to
UTF-8 by default. -I suspect it has to do with- This is due to backwards
compatibility. Both the parameter and the configuration are documented in the
[request parameter handling
documentation|https://sling.apache.org/documentation/the-sling-engine/request-parameters.html#character-encoding-1]
I would be inclined to close this issue "Not a problem" or "Invalid", unless
you have a suggestion what should be fixed.
was (Author: jsedding):
You can send a parameter {{\_charset\_=utf-8}} when you upload the files. That
should have the same effect as adjusting the default parameter encoding. I
can't remember at the moment why the default parameter encoding is not set to
UTF-8 by default. I suspect it has to do with backwards compatibility.
I would be inclined to close this issue "Not a problem" or "Invalid", unless
you have a suggestion what should be fixed.
> PDF file name is garbled
>
>
> Key: SLING-10611
> URL: https://issues.apache.org/jira/browse/SLING-10611
> Project: Sling
> Issue Type: Improvement
> Components: App CMS
>Affects Versions: App CMS 1.0.2
>Reporter: James Raynor
>Priority: Major
> Attachments: 1.png
>
>
> Steps to reproduce:
> Create /static/clientlibs/test, a directory, and upload the following PDF
> files:
> 简体中文. 繁體中文. 한국어.pdf
> English.Español.Русский.pdf
> Italiano.Deutsch.Français.pdf
> Español (México).Português.pdf
> After uploading the PDF file name is garbled, and can not be deleted.
> This problem has been plaguing me for a long time, I do not know how to
> solve, only recently found a solution.
> Goto [http://localhost:8080/system/console/configMgr]
> Find the "Apache Sling Request Parameter Handling"
> Set Default Parameter Encoding value to UTF-8
> It is recommended to set the config default value to UTF-8 automatically
> after SlingCMS is started, many users should not know how to solve this
> problem.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-10611) PDF file name is garbled
[
https://issues.apache.org/jira/browse/SLING-10611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380432#comment-17380432
]
Julian Sedding commented on SLING-10611:
You can send a parameter {{\_charset\_=utf-8}} when you upload the files. That
should have the same effect as adjusting the default parameter encoding. I
can't remember at the moment why the default parameter encoding is not set to
UTF-8 by default. I suspect it has to do with backwards compatibility.
I would be inclined to close this issue "Not a problem" or "Invalid", unless
you have a suggestion what should be fixed.
> PDF file name is garbled
>
>
> Key: SLING-10611
> URL: https://issues.apache.org/jira/browse/SLING-10611
> Project: Sling
> Issue Type: Improvement
> Components: App CMS
>Affects Versions: App CMS 1.0.2
>Reporter: James Raynor
>Priority: Major
> Attachments: 1.png
>
>
> Steps to reproduce:
> Create /static/clientlibs/test, a directory, and upload the following PDF
> files:
> 简体中文. 繁體中文. 한국어.pdf
> English.Español.Русский.pdf
> Italiano.Deutsch.Français.pdf
> Español (México).Português.pdf
> After uploading the PDF file name is garbled, and can not be deleted.
> This problem has been plaguing me for a long time, I do not know how to
> solve, only recently found a solution.
> Goto [http://localhost:8080/system/console/configMgr]
> Find the "Apache Sling Request Parameter Handling"
> Set Default Parameter Encoding value to UTF-8
> It is recommended to set the config default value to UTF-8 automatically
> after SlingCMS is started, many users should not know how to solve this
> problem.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SLING-10394) JUnit Core's HtmlReporter does not correctly report failed assumptions
[
https://issues.apache.org/jira/browse/SLING-10394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding closed SLING-10394.
--
> JUnit Core's HtmlReporter does not correctly report failed assumptions
> --
>
> Key: SLING-10394
> URL: https://issues.apache.org/jira/browse/SLING-10394
> Project: Sling
> Issue Type: Improvement
> Components: JUnit Core
>Affects Versions: JUnit Core 1.1.2
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: JUnit Core 1.1.6
>
>
> Currently the {{HtmlReporter}} of JUnit Core reports failed assumptions as
> failures. They should instead be reported more quietly as failed assumptions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SLING-10510) Update to Parent 43
[ https://issues.apache.org/jira/browse/SLING-10510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding closed SLING-10510. -- > Update to Parent 43 > --- > > Key: SLING-10510 > URL: https://issues.apache.org/jira/browse/SLING-10510 > Project: Sling > Issue Type: Task > Components: JUnit Core, Testing >Affects Versions: JUnit Core 1.1.2 >Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > Fix For: JUnit Core 1.1.6 > > > Update parent pom to version 43. -- This message was sent by Atlassian Jira (v8.3.4#803005)
