Re: [PR] Clarify dependency policy of Sling bundles [sling-site]
cziegeler commented on PR #149: URL: https://github.com/apache/sling-site/pull/149#issuecomment-1874916920 If we all agree that this is a "should" then I'm totally happy. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Clarify dependency policy of Sling bundles [sling-site]
enapps-enorman commented on PR #149: URL: https://github.com/apache/sling-site/pull/149#issuecomment-1874914137 > For me the key word is "should" - it doesn't prevent us from updating a dependency for whatever reason, being it a security bug or a regression or whatever. Once we try to come up with a policy that fits all use cases, we most likely will spent a lot of time on it, just to find out that we missed something. And even if we think we can do this perfect policy are we seriously thinking about having a policy police? Well, if you read my suggestion again you would see that it says "should" as well. It just tries to define some best practice guidance. If that is too complex for you, then go ahead and leave it ambiguous and continue to be afraid of changing anything. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Clarify dependency policy of Sling bundles [sling-site]
cziegeler commented on PR #149: URL: https://github.com/apache/sling-site/pull/149#issuecomment-1874877870 For me the key word is "should" - it doesn't prevent us from updating a dependency for whatever reason, being it a security bug or a regression or whatever. Once we try to come up with a policy that fits all use cases, we most likely will spent a lot of time on it, just to find out that we missed something. And even if we think we can do this perfect policy are we seriously thinking about having a policy police? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Clarify dependency policy of Sling bundles [sling-site]
enapps-enorman commented on PR #149: URL: https://github.com/apache/sling-site/pull/149#issuecomment-1874774474 @kwin > Can you propose changes for sections you don't agree with or are you fine with the remarks from @cziegeler? The following is the only statement that I would like to see more clarity on since the "lowest version" doesn't consider known security vulnerabilities when choosing the version to depend on. > The version of the module dependency should be selected according to the following rule: **The lowest version providing the functionality required by the module (or bundle)**. By required functionality we basically mean provided API. For me, the rules for dependency version should prefer the oldest version that doesn't contain any known security vulnerability with guidelines like this: 1. When the generated "Import-Package" clause does not materially change then it should be preferred to bump the dependency to this version. This would make the security scanning tools not flag this as problem and should not alter the binary compatibility at all. 2. When the generated "Import-Package" clause does materially change, then bump the "minor segment" of the bundle version number and continue further development with this as the new base version number. Changing the "minor segment" of the bundle version leaves that previous minor bundle version namespace available for any fixes that need to be backported and released on the older branch. This should make it possible to support consumers who can't upgrade to the new version. This backport scenario would probably be rare so I would treat it as an "on demand" situation. I would imagine that some of this decision could be assisted with a bnd plugin that could do some calculations against the baseline version of the bundle. Maybe some codified tooling that enforces the above and the other bundle version rules from https://sling.apache.org/documentation/development/version-policy.html#evolution-of-bundle-versions -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (SLING-12217) Reduce resource lookups in Sling Model resolution
[ https://issues.apache.org/jira/browse/SLING-12217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Hoh updated SLING-12217: -- Summary: Reduce resource lookups in Sling Model resolution (was: Reduce resource lookups) > Reduce resource lookups in Sling Model resolution > - > > Key: SLING-12217 > URL: https://issues.apache.org/jira/browse/SLING-12217 > Project: Sling > Issue Type: Task > Components: Sling Models >Affects Versions: Models Implementation 1.6.4 >Reporter: Joerg Hoh >Priority: Major > > While analyzing repository access, I found a pattern in the Scripting HTL > implementation, which leads to multiple invocations of the same check on the > same resources in the Sling Model ModelAdapterFactory. > Invocation at > [JavaUseProvider.loadObject()|https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/690a818692bd08c3f6a49e842ea530cc3e60e3ad/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/use/JavaUseProvider.java#L172]: > * modelAdapterFactory.canCreateModelFromAdaptable() > * modelAdapterFactory.createModel > those methods directly or indirectly call > [org.apache.sling.models.impl.AdapterImplementations.lookup()|https://github.com/apache/sling-org-apache-sling-models-impl/blob/cf088713c402177b9d96a5229567804510ef9918/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java#L192], > which calls > [getModelClassForResource|https://github.com/apache/sling-org-apache-sling-models-impl/blob/cf088713c402177b9d96a5229567804510ef9918/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java#L302]; > and there multiple resources are resolved, based on the provided > resourceType. > I benchmarked this code using a simple AEM sample page (WKND) using HTL and > Sling Models. I found this code is responsible to the creation of 712 JCR > Node resource objects (the total page rendering triggered the creation of > more than 10k, so these are around 7%). When deduplicating the requested > paths, I found that only 36 distinct paths were resolved with these 712 JCR > Node resources. > That means that with proper caching (probably using the > ResourceResolver.getPropertyMap) around 6.5% of repository access could be > avoided, leading to a page rendering improvement in about the same range. > > > > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12217) Reduce resource lookups
Joerg Hoh created SLING-12217: - Summary: Reduce resource lookups Key: SLING-12217 URL: https://issues.apache.org/jira/browse/SLING-12217 Project: Sling Issue Type: Task Components: Sling Models Affects Versions: Models Implementation 1.6.4 Reporter: Joerg Hoh While analyzing repository access, I found a pattern in the Scripting HTL implementation, which leads to multiple invocations of the same check on the same resources in the Sling Model ModelAdapterFactory. Invocation at [JavaUseProvider.loadObject()|https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/690a818692bd08c3f6a49e842ea530cc3e60e3ad/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/use/JavaUseProvider.java#L172]: * modelAdapterFactory.canCreateModelFromAdaptable() * modelAdapterFactory.createModel those methods directly or indirectly call [org.apache.sling.models.impl.AdapterImplementations.lookup()|https://github.com/apache/sling-org-apache-sling-models-impl/blob/cf088713c402177b9d96a5229567804510ef9918/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java#L192], which calls [getModelClassForResource|https://github.com/apache/sling-org-apache-sling-models-impl/blob/cf088713c402177b9d96a5229567804510ef9918/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java#L302]; and there multiple resources are resolved, based on the provided resourceType. I benchmarked this code using a simple AEM sample page (WKND) using HTL and Sling Models. I found this code is responsible to the creation of 712 JCR Node resource objects (the total page rendering triggered the creation of more than 10k, so these are around 7%). When deduplicating the requested paths, I found that only 36 distinct paths were resolved with these 712 JCR Node resources. That means that with proper caching (probably using the ResourceResolver.getPropertyMap) around 6.5% of repository access could be avoided, leading to a page rendering improvement in about the same range. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12216) Remove DistPublisherJMX
[ https://issues.apache.org/jira/browse/SLING-12216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801929#comment-17801929 ] Konrad Windszus commented on SLING-12216: - Who is „we“? Wouldn’t it make sense to ask the community first? > Remove DistPublisherJMX > --- > > Key: SLING-12216 > URL: https://issues.apache.org/jira/browse/SLING-12216 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Christian Schneider >Priority: Major > Fix For: Content Distribution Journal Core 0.3.0 > > > We do not really use the JMX bean. So I think we should remove that code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12216) Remove DistPublisherJMX
[ https://issues.apache.org/jira/browse/SLING-12216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved SLING-12216. - Resolution: Fixed > Remove DistPublisherJMX > --- > > Key: SLING-12216 > URL: https://issues.apache.org/jira/browse/SLING-12216 > Project: Sling > Issue Type: Improvement > Components: Content Distribution >Reporter: Christian Schneider >Assignee: Christian Schneider >Priority: Major > Fix For: Content Distribution Journal Core 0.3.0 > > > We do not really use the JMX bean. So I think we should remove that code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12216) Remove DistPublisherJMX
Christian Schneider created SLING-12216: --- Summary: Remove DistPublisherJMX Key: SLING-12216 URL: https://issues.apache.org/jira/browse/SLING-12216 Project: Sling Issue Type: Improvement Components: Content Distribution Reporter: Christian Schneider Assignee: Christian Schneider Fix For: Content Distribution Journal Core 0.3.0 We do not really use the JMX bean. So I think we should remove that code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[Jenkins] Sling » Modules » sling-org-apache-sling-starter » master #1206 is BROKEN
/org.apache.sling.starter-13-SNAPSHOT-oak_mongo_far.far [INFO] DOCKER> [mongo:4.4.6] "mongo": Stop and removed container 9df81c8eebf7 after 0 ms [INFO] [INFO] --- failsafe:3.0.0-M5:verify (default) @ org.apache.sling.starter --- [INFO] Failsafe report directory: /home/jenkins/jenkins-agent/workspace/_org-apache-sling-starter_master/jdk_17_latest/target/failsafe-reports [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 08:40 min [INFO] Finished at: 2024-01-02T11:26:43Z [INFO] [INFO] [jenkins-event-spy] Generated /home/jenkins/jenkins-agent/workspace/_org-apache-sling-starter_master/jdk_17_latest@tmp/withMaven9505f324/maven-spy-20240102-111802-35810812168770112060892.log [ERROR] Failed to execute goal org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M5:verify (default) on project org.apache.sling.starter: There are test failures. [ERROR] [ERROR] Please refer to /home/jenkins/jenkins-agent/workspace/_org-apache-sling-starter_master/jdk_17_latest/target/failsafe-reports for the individual test results. [ERROR] Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream. [ERROR] -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M5:verify (default) on project org.apache.sling.starter: There are test failures. Please refer to /home/jenkins/jenkins-agent/workspace/_org-apache-sling-starter_master/jdk_17_latest/target/failsafe-reports for the individual test results. Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream. at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:333) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174) at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75) at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162) at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101) at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906) at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283) at org.apache.maven.cli.MavenCli.main (MavenCli.java:206) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:568) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:283) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:226) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:407) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:348) Caused by: org.apache.maven.plugin.MojoFailureException: There are test failures. Please refer to /home/jenkins/jenkins-agent/workspace/_org-apache-sling-starter_master/jdk_17_latest/target/failsafe-reports for the individual test results. Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream. at org.apache.maven.plugin.surefire.SurefireHelper.throwException (SurefireHelper.java:271) at org.apache.maven.plugin.surefire.SurefireHelper.reportExecution (SurefireHelper.java:159) at org.apache.maven.plugin.failsafe.VerifyMojo.execute (VerifyMojo.java:192) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoE
[jira] [Resolved] (SLING-12215) javadoc of ResourceUtil.normalize does not match implementation
[ https://issues.apache.org/jira/browse/SLING-12215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-12215. -- Resolution: Fixed https://github.com/apache/sling-org-apache-sling-api/commit/ec0f8cf8baa2c5a12b3987d5f39e33e8278b5fa3 > javadoc of ResourceUtil.normalize does not match implementation > --- > > Key: SLING-12215 > URL: https://issues.apache.org/jira/browse/SLING-12215 > Project: Sling > Issue Type: Improvement > Components: API >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Minor > Fix For: API 2.27.4 > > > The javadoc mentions that it returns null on relative paths, but the method > actually handles them -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12215) javadoc of ResourceUtil.normalize does not match implementation
Carsten Ziegeler created SLING-12215: Summary: javadoc of ResourceUtil.normalize does not match implementation Key: SLING-12215 URL: https://issues.apache.org/jira/browse/SLING-12215 Project: Sling Issue Type: Improvement Components: API Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: API 2.27.4 The javadoc mentions that it returns null on relative paths, but the method actually handles them -- This message was sent by Atlassian Jira (v8.20.10#820010)
