Re: [VOTE] Release Apache Sling JCR Base 3.2.0
+1 On Mon, Oct 2, 2023 at 1:10 AM Carsten Ziegeler wrote: > Hi, > > We solved 2 issues in this release: > https://issues.apache.org/jira/projects/SLING/versions/12353098 > > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2789/ > > You can use this UNIX script to download the release and verify the > signatures: > > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD > > Usage: > sh check_staged_release.sh 2789 /tmp/sling-staging > > Please vote to approve this release: > >[ ] +1 Approve the release >[ ] 0 Don't care >[ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. > > Regards > Carsten > -- > Carsten Ziegeler > Adobe > cziege...@apache.org >
[jira] [Created] (SLING-12062) add LazyBindings.putOnly
Joerg Hoh created SLING-12062:
-
Summary: add LazyBindings.putOnly
Key: SLING-12062
URL: https://issues.apache.org/jira/browse/SLING-12062
Project: Sling
Issue Type: Task
Components: API
Affects Versions: API 2.27.2
Reporter: Joerg Hoh
The LazyBindings support the lazy evaluation of values to avoid the potential
costly resolution of values at provisioning time (the values are only resolved
when requested via {{get}}).
But if for some reasons the same key is put twice into a LazyBinding, the
second call to {{put(key, value)}} resolves the already provided value and
returns it, but this return value of {{put}} is often ignored.
So the LazyBindings should have a {{putOnly(key,value)}} method, which behaves
the same way as the existing {{put}}, but does not return the (resolved)
previous value.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [RT] Path to Jakarta Servlet Specification
Hi, On Sun, Oct 1, 2023 at 3:59 PM Carsten Ziegeler wrote: > ..It seems the Java world around us is moving to Jakarta and if we want to > benefit from upcoming new features in that world, we eventually have to > move... The move looks like a lot of work, so I think we should be able to list actual benefits before deciding to do it. Especially if there's a cost to users of the Sling APIs - the overall cost can be huge. Do people know what exactly we might miss by not moving? Are there areas where the current servlet APIs prevent Sling's progress ? > ...Option 3: do nothing now and wait until this switch is actually becoming > a real problem... That would be my preferred option right now, but answers to my above questions might change that. -Bertrand
[jira] [Commented] (SLING-11662) Endless loop in QuartzSchedulerThread.run() with maxPoolSize == queueSize
[
https://issues.apache.org/jira/browse/SLING-11662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771066#comment-17771066
]
Stefan Egli commented on SLING-11662:
-
[~cziegeler], thx for reactivating this - got lost in the noise indeed. I'll
have a look at the PR.
> Endless loop in QuartzSchedulerThread.run() with maxPoolSize == queueSize
> -
>
> Key: SLING-11662
> URL: https://issues.apache.org/jira/browse/SLING-11662
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Scheduler 2.7.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When configuring the ThreadPool with maxPoolSize == queueSize and endless
> loop (can) happen(s) in QuartzSchedulerThread.run() which manifests as
> follows:
> {noformat}
> "MyPool_QuartzSchedulerThread" #123 prio=5 os_prio=0 cpu=5123456.78ms
> elapsed=5163.45s tid=0x12345678ff00 nid=0x1234 runnable
> [0x87654321ff00]
>java.lang.Thread.State: RUNNABLE
> at
> org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:413)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[Jenkins] Sling » Modules » sling-org-apache-sling-starter » master #1047 is FIXED
Please see https://ci-builds.apache.org/job/Sling/job/modules/job/sling-org-apache-sling-starter/job/master/1047/ for details. No further emails will be sent until the status of the build is changed.
Re: [RT] Path to Jakarta Servlet Specification
A project that might help if we try option 2: https://github.com/eclipse/transformer (initially written for exactly this use case) Regards Carsten On 01.10.2023 15:59, Carsten Ziegeler wrote: Hi, we should discuss whether and if how we want to move to the Jakarta Servlet Specification. For everyone this is a "quick" recap of todays landscape (in general): - Sling is based on Servlet 2/3 which uses the javax.servlet package namespace - Servlet 4 is the last specification using the javax.servlet namespace - With the move of all enterprise specifications to the Eclipse, all specification went through package renaming. Servlet 5 is the first version using the jakarta.servlet package namespace. It is identical to Servlet 4 - except for the packages. - In general, migration from Servlet 4 to Servlet 5 "just" requires all packages to be renamed; this can be done in source or binaries - at build time or at runtime. - The latest specification is Servlet 6 which added minor features to Servlet 5 *but* removed all things that were deprecated in Servlet 5. This means if you have code using those deprecated methods, you need to adjust your code to get to Servlet 6 - It seems that servlet engines like Jetty (which we use through Apache Felix) require users to migrate. Jetty 9/10 support javax.servlet 3/4, Jetty 11 only supports Jakarta Servlet 5 and Jetty 12 only support Jakarta Servlet 6. - OSGi Specifications: The old http service is tied to javax.servlet. This one should not be used as it got replaced by the http whiteboard. - OSGi Specifications: http whiteboard supports Servlet 3/4 - OSGi Specifications: servlet whiteboard supports Servlet 5 (and in theory Servlet 6). - OSGi Specifications: It is possible to run all of the above three specifications in parallel - Implementation: Apache Felix Http Jetty 5.x supports all of the above OSGi specifications and Servlet API 2 to 5. You can mix and match old code with new code - this allows for an easier upgrade path for consumer as you can transitions parts of your code base one after the other. When we are talking about Sling, things get more complicated as most of our API uses javax.servlet as part of the API, so simply changing that API from javax.servlet to jakarta.servlet will break everyone out there. Basically all of our API is affected, unfortunately including all the resource resolver related API packages!. The Apache Felix Webconsole was in a similar situation as Sling but with a way smaller API. Here we just created a new API next to the old one, now allowing to run plugins using old and new API in parallel. This support works in every servlet engine using javax.servlet - and eventually will move to require a jakarta.servlet based engine. So the first question for us is now, do we want to support the Jakarta Servlet API? It seems the Java world around us is moving to Jakarta and if we want to benefit from upcoming new features in that world, we eventually have to move. There are different options to do this move: Option 1: provide new API interfaces based on Jakarta - parallel to the old ones with side-by-side packages (similar to the web console). Maybe this should focus on Servlet 6 (with removed deprecated stuff), to not have two migration steps for the users. While this is also an opportunity to clean up our API around the Servlet API, it unfortunately includes a complete fork of our API - and the implementation to support old and new one will be pretty complex. Option 2: Update the existing API directly to Servlet 5/6. This breaks all code out there and forces it to migrate. This is only an option if we could provide tooling (byte code rewriting?) that either at assembly or runtime rewrites usage of the old packages to the new packages. This approach would not allow us to clean up the API. That would need to be handled separately. Option 3: do nothing now and wait until this switch is actually becoming a real problem. Giving the complexity of this problem, option 3 is maybe not the best choice. Option 1 is very tempting, but I fear the complexity and risk involved. I did this work for the web console and it was already quite challenging there. If Option 2 would work, this could be a nice way out. Thoughts? Maybe there are better options? Regards Carsten -- Carsten Ziegeler Adobe cziege...@apache.org
[jira] [Commented] (SLING-11500) Commons-Metrics: Update to dropwizard-metrics 4.x
[ https://issues.apache.org/jira/browse/SLING-11500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771043#comment-17771043 ] Carsten Ziegeler commented on SLING-11500: -- I checked the code, it seems the "only" problem is the registration of MetricsRegistry - clients might pick that one up and create metrics directly through the dropwizard library. Unfortunately, the 4.x version of dropwizard is not compatible to 3.x (which we use), so this would be a breaking change > Commons-Metrics: Update to dropwizard-metrics 4.x > - > > Key: SLING-11500 > URL: https://issues.apache.org/jira/browse/SLING-11500 > Project: Sling > Issue Type: Task > Components: Commons >Affects Versions: Commons Metrics 1.2.10 >Reporter: Joerg Hoh >Priority: Major > > We are still using a version 3.2.3 from 2017. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-9455) JsonItemWriter
[ https://issues.apache.org/jira/browse/SLING-9455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-9455. - Resolution: Won't Fix > JsonItemWriter > -- > > Key: SLING-9455 > URL: https://issues.apache.org/jira/browse/SLING-9455 > Project: Sling > Issue Type: New Feature > Components: Commons >Affects Versions: Commons JSON 2.0.18 > Environment: Sling Starter >Reporter: Juerg Meier >Priority: Major > > Sling 8 came with an org.apache.sling.commons.json bundle/package. The .jcr > sub-package contained two classes: > * JsonItemWriter > * JsonJcrNode > (javadoc > [here|https://sling.apache.org/apidocs/sling8/org/apache/sling/commons/json/jcr/package-summary.html) > These two classes allowed for serializing a sling resource to well formated > JSON and a JCR node to an org.apache.sling.commons.json.JSONObject, > respectively. > For legal reasons, this package was discontinued and is not present anymore > in later versions, including the current Sling 11 version. > Consequently, Sling 11 lacks of a simple yet application-controllable way to > serialize a Resource directly to a JSON string. However, many API calls, used > in particular by client-side Javascript frameworks (e.g. for Single Page > Apps), rely heavily on JSON. > Hence, it would be desirable to have the Sling 8 JSON package (or similar) > back in Sling. The following functionality should be present to have a > flexible JSON generator available within Sling: > * direct conversion of Nodes/Resources to a String containing JSON > * application control of node recursion levels (child nodes as JSON objects) > * should allow to set a negative list of properties (those not to render in > the output) > * proper rendering of all JCR property types to JSON including > ** date format definition (default = ISO8601) > ** multi-values support (as JSON arrays) > ** proper escaping of special chars in Strings > * adding additional string/value pairs by the application (i.e. not > originating from the dumped Resource) > See also [thread on the sling-users mailing list starting 12 May > 2020/"Resource to json > serializing"|https://lists.apache.org/thread.html/r9756cb97eb77d2d5c0779f4003ab166b54ee0fc424993b3dedf4a6c2%40%3Cusers.sling.apache.org%3E] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-7676) Refactor LogWriter to use SizeAndTimeBasedRollingPolicy
[
https://issues.apache.org/jira/browse/SLING-7676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-7676.
-
Resolution: Won't Fix
> Refactor LogWriter to use SizeAndTimeBasedRollingPolicy
> ---
>
> Key: SLING-7676
> URL: https://issues.apache.org/jira/browse/SLING-7676
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Affects Versions: Commons Log 5.1.6
>Reporter: Julian Sedding
>Priority: Major
>
> As discussed in SLING-7660 and LOGBACK-266, the currently used
> {{FixedWindowRollingPolicy}} can be expensive when a lot of old files should
> be retained. This is because all files need to be renamed during log-file
> rotation, which can be expensive on some file systems.
> The recommendation is to use {{SizeAndTimeBasedRollingPolicy}} instead, which
> allows limiting the size of individual log files by adding a date field and a
> counter to each log-file's name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-6282) Provide Commons Caching Ehcache
[ https://issues.apache.org/jira/browse/SLING-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-6282. - Resolution: Won't Fix > Provide Commons Caching Ehcache > --- > > Key: SLING-6282 > URL: https://issues.apache.org/jira/browse/SLING-6282 > Project: Sling > Issue Type: New Feature > Components: Commons >Reporter: Oliver Lietz >Assignee: Oliver Lietz >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-5750) Dynamically load different component renditions
[ https://issues.apache.org/jira/browse/SLING-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-5750. - Resolution: Won't Fix > Dynamically load different component renditions > --- > > Key: SLING-5750 > URL: https://issues.apache.org/jira/browse/SLING-5750 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Feike Visser >Priority: Major > > In the current setup in Sling there is 1:1 relation between a component and > the code that implements this components. > In a multi-tenant/multi-brand environment you have a need to switch this > dynamically based on the tenant that you are in. > Example > [default] > Component A -> /apps/components/componeneta/componeneta.html > [Tenant A] > Component A -> /apps/tenanta/componeneta.html > [Tenant B] > Component A -> /apps/tenantb/componeneta.html > Content structure > /tenanta/ > property: sling:scriptFolder -> /apps/tenanta > /tenantb/ > property: sling:scriptFolder -> /apps/tenantb > Suggestion: If we would implement a dynamic search path the implementation > can choose itself where to point to when we are in a multi-tenant environment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-6281) Provide Commons Caching (JSR 107/JCache)
[
https://issues.apache.org/jira/browse/SLING-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-6281.
-
Resolution: Won't Fix
> Provide Commons Caching (JSR 107/JCache)
>
>
> Key: SLING-6281
> URL: https://issues.apache.org/jira/browse/SLING-6281
> Project: Sling
> Issue Type: New Feature
> Components: Commons
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
>
> current goals and non-goals:
> * (+) API aligned to JSR 107/JCache
> * (+) providing {{Cache}}s as OSGi Services
> * (+) providing {{CacheManager}}s as OSGi Services
> * (+) OSGi configuration support
> * (-) cache invalidation
> * (-) scope handling (request, thread)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-5317) PropertiesUtil does not have a toFloat method
[ https://issues.apache.org/jira/browse/SLING-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-5317. - Resolution: Won't Fix > PropertiesUtil does not have a toFloat method > - > > Key: SLING-5317 > URL: https://issues.apache.org/jira/browse/SLING-5317 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Satya Deep Maheshwari >Priority: Minor > > org.apache.sling.commons.osgi.PropertiesUtil does not have a toFloat method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-5223) Webconsole of FSClassloader should be able to force recompilation of scripts
[ https://issues.apache.org/jira/browse/SLING-5223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-5223. - Resolution: Won't Fix > Webconsole of FSClassloader should be able to force recompilation of scripts > > > Key: SLING-5223 > URL: https://issues.apache.org/jira/browse/SLING-5223 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: File System ClassLoader 1.0.2 >Reporter: Joerg Hoh >Priority: Major > > The filesystem classloader should able to trigger a recompilation of all > scripts. This should be doable by removing all files in the classes directory > of the bundle. > (This is the equivalent of purging /var/classes when using the JCR > Classloader.) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-4757) Improve test coverage and add integration tests to the contentdetection module
[ https://issues.apache.org/jira/browse/SLING-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-4757. - Fix Version/s: (was: Content Detection Support 1.0.2) Resolution: Won't Fix > Improve test coverage and add integration tests to the contentdetection module > -- > > Key: SLING-4757 > URL: https://issues.apache.org/jira/browse/SLING-4757 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Bertrand Delacretaz >Assignee: Petr Shypila >Priority: Major > Attachments: > FileNameExtractorImpl_Injection_failed__ClassNotFoundException.patch, > content-tampering-test.patch, week2-part1-unit-tests.patch, > week2-part2-integration-tests.patch > > > The new SLING-4694 contentdetection module has reasonable test coverage but > there are some gaps, and it's also missing some integration tests to verify > that the services provided by the bundle are correctly made available in an > OSGI environment. > I'll take this opportunity to ask our GSoC student [~petr.shypila] to expand > these tests, as that's a good example of what we're trying to do with his > tests improvement project. > So [~petr.shypila] here's your "mission" ;-) > Buliding bundles/commons/contentdetection with with -Pjacoco-report and > looking at target/site/jacoco/index.html shows that a few things are not > tested. The first step is to add the missing unit tests to improve that, > maybe provide a first patch with just that. > Then, we'd like to add integration tests that start this bundle in an OSGi > environment and verify that the ContentAwareMimeTypeService and > FileNameExtractor services are available and work. No need to duplicate the > unit tests, just verify that the services are here and work in a simple case. > The best way to do this is probably with Pax Exam, the > ResourceBundleProviderIT. is a good example of that and there are other > examples in our codebase if you search for *IT.java files that contain > "pax.exam". > As usual, try to minimize changes to the pom (except for what's directly > related to testing) and to non-test code. > Feel free to ask if you have any questions of course, either here for minor > ones or on the dev list for larger discussions. > [1] > https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/i18n/src/test/java/org/apache/sling/i18n/it/ResourceBundleProviderIT.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-11662) Endless loop in QuartzSchedulerThread.run() with maxPoolSize == queueSize
[
https://issues.apache.org/jira/browse/SLING-11662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771032#comment-17771032
]
Carsten Ziegeler commented on SLING-11662:
--
[~stefanegli] Any update here? Should we merge?
> Endless loop in QuartzSchedulerThread.run() with maxPoolSize == queueSize
> -
>
> Key: SLING-11662
> URL: https://issues.apache.org/jira/browse/SLING-11662
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Scheduler 2.7.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When configuring the ThreadPool with maxPoolSize == queueSize and endless
> loop (can) happen(s) in QuartzSchedulerThread.run() which manifests as
> follows:
> {noformat}
> "MyPool_QuartzSchedulerThread" #123 prio=5 os_prio=0 cpu=5123456.78ms
> elapsed=5163.45s tid=0x12345678ff00 nid=0x1234 runnable
> [0x87654321ff00]
>java.lang.Thread.State: RUNNABLE
> at
> org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:413)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SLING-11662) Endless loop in QuartzSchedulerThread.run() with maxPoolSize == queueSize
[
https://issues.apache.org/jira/browse/SLING-11662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned SLING-11662:
Assignee: Stefan Egli
> Endless loop in QuartzSchedulerThread.run() with maxPoolSize == queueSize
> -
>
> Key: SLING-11662
> URL: https://issues.apache.org/jira/browse/SLING-11662
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Scheduler 2.7.12
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When configuring the ThreadPool with maxPoolSize == queueSize and endless
> loop (can) happen(s) in QuartzSchedulerThread.run() which manifests as
> follows:
> {noformat}
> "MyPool_QuartzSchedulerThread" #123 prio=5 os_prio=0 cpu=5123456.78ms
> elapsed=5163.45s tid=0x12345678ff00 nid=0x1234 runnable
> [0x87654321ff00]
>java.lang.Thread.State: RUNNABLE
> at
> org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:413)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-10506) Document inappropriate Sonar rules
[
https://issues.apache.org/jira/browse/SLING-10506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771017#comment-17771017
]
Fabrice Bellingard commented on SLING-10506:
Hello [~rombert],
I can help on this. I can create a specific QP that suits your needs and bulk
activate it on all of the sling projects (that will be easy because the
projects are very well named). Tell me when you want me to do it.
In return, may I ask you a favor? I am sure that our Java Ecosystem Product
Manager (at SonarSource) would be very interested to understand why those rules
are inappropriate for your context. Would that be possible to update the
description of this JIRA ticket with a quick description of why each rule does
not make sense for you?
> Document inappropriate Sonar rules
> --
>
> Key: SLING-10506
> URL: https://issues.apache.org/jira/browse/SLING-10506
> Project: Sling
> Issue Type: Task
> Components: Build and Source Control, CI
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
>
> * {{java:S100}} (https://rules.sonarsource.com/java/RSPEC-100)
> * {{java:S112}} (https://rules.sonarsource.com/java/RSPEC-112)
> * {{java:S1117}} (https://rules.sonarsource.com/java/RSPEC-1117)
> * {{java:S1149}} (https://rules.sonarsource.com/java/RSPEC-1149)
> * {{java:S1989}} (https://rules.sonarsource.com/java/RSPEC-1989)
> * {{java:S2226}} (https://rules.sonarsource.com/java/RSPEC-2226)
> * {{java:S3077}} (https://rules.sonarsource.com/java/RSPEC-3077)
> * {{java:S6212}} (https://rules.sonarsource.com/java/RSPEC-6212)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12052) Add search function to the Sling website
[
https://issues.apache.org/jira/browse/SLING-12052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz resolved SLING-12052.
-
Resolution: Fixed
Downgrading Node.js to {{v16.6.0}} fixed the GLIBC issue, the searchbox is now
live.
> Add search function to the Sling website
>
>
> Key: SLING-12052
> URL: https://issues.apache.org/jira/browse/SLING-12052
> Project: Sling
> Issue Type: Task
> Components: Site
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> A site search function would be useful on https://sling.apache.org/
> The https://community.apache.org/ and https://www.apache.org/ websites are
> successfully using https://pagefind.app/ which is fairly simple to integrate,
> we might do the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12052) Add search function to the Sling website
[
https://issues.apache.org/jira/browse/SLING-12052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771010#comment-17771010
]
Bertrand Delacretaz commented on SLING-12052:
-
I have merged PR #133 but the
[build|https://ci-builds.apache.org/job/Sling/job/modules/job/sling-site/job/master/]
fails when trying to run {{npx pagefind}} :
{quote}/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found
(required by
/home/jenkins/712657a4/workspace/ling_modules_sling-site_master_2/jdk_11_latest/target/node/node)
{quote}
> Add search function to the Sling website
>
>
> Key: SLING-12052
> URL: https://issues.apache.org/jira/browse/SLING-12052
> Project: Sling
> Issue Type: Task
> Components: Site
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> A site search function would be useful on https://sling.apache.org/
> The https://community.apache.org/ and https://www.apache.org/ websites are
> successfully using https://pagefind.app/ which is fairly simple to integrate,
> we might do the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SLING-12052) Add search function to the Sling website
[ https://issues.apache.org/jira/browse/SLING-12052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz reassigned SLING-12052: --- Assignee: Bertrand Delacretaz > Add search function to the Sling website > > > Key: SLING-12052 > URL: https://issues.apache.org/jira/browse/SLING-12052 > Project: Sling > Issue Type: Task > Components: Site >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > > A site search function would be useful on https://sling.apache.org/ > The https://community.apache.org/ and https://www.apache.org/ websites are > successfully using https://pagefind.app/ which is fairly simple to integrate, > we might do the same. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SLING-10899) Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached
[ https://issues.apache.org/jira/browse/SLING-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771007#comment-17771007 ] Henry Kuijpers edited comment on SLING-10899 at 10/2/23 8:39 AM: - I agree! That way, the JcrValueMap's cache is actually useful: You have the same ValueMap across multiple Filter / Servlet / .. calls. And the next filter/servlet/component/. benefits from the cache inside JcrValueMap. was (Author: henry kuijpers): I agree! That way, the JcrValueMap's cache is actually useful: You have the same ValueMap across multiple Filter / Servlet / .. calls. > Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached > -- > > Key: SLING-10899 > URL: https://issues.apache.org/jira/browse/SLING-10899 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 3.0.22 >Reporter: Henry Kuijpers >Priority: Major > > I was performance testing our application. There is a specific part of the > code where we have a set of ~500 resources and we sort them based on a few > properties of the resources. Multiple properties are used (which results in > multiple calls to getValueMap). The sorting is done using a comparator, so > the logic that determines the order is accessed numerous times. > We've seen quite a decrease in performance when doing this with Resources > that are of type JcrNodeResource. Turns out that the result of getValueMap > (or adaptTo((Value)Map.class)) is not cached. > As you can see in the adaptTo()-method implementation: > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L136 > this call bypasses the AdapterFactory framework and also bypasses any > caching that happens over there. > What's even more unfortunate, is that JcrValueMap is implementing caching via > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/6e13f4d315ddf2804d2e16c55faee18e805b618e/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java#L49 > . That caching is not leveraged properly, because every call to getValueMap > returns a new JcrValueMap, instead of reusing a previously created one. > One change that can be done is maybe converting the logic inside the > adaptTo()-method to a dedicated AdapterFactory implementation, so that > caching is done by default? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-10899) Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached
[ https://issues.apache.org/jira/browse/SLING-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771007#comment-17771007 ] Henry Kuijpers commented on SLING-10899: I agree! That way, the JcrValueMap's cache is actually useful: You have the same ValueMap across multiple Filter / Servlet / .. calls. > Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached > -- > > Key: SLING-10899 > URL: https://issues.apache.org/jira/browse/SLING-10899 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 3.0.22 >Reporter: Henry Kuijpers >Priority: Major > > I was performance testing our application. There is a specific part of the > code where we have a set of ~500 resources and we sort them based on a few > properties of the resources. Multiple properties are used (which results in > multiple calls to getValueMap). The sorting is done using a comparator, so > the logic that determines the order is accessed numerous times. > We've seen quite a decrease in performance when doing this with Resources > that are of type JcrNodeResource. Turns out that the result of getValueMap > (or adaptTo((Value)Map.class)) is not cached. > As you can see in the adaptTo()-method implementation: > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L136 > this call bypasses the AdapterFactory framework and also bypasses any > caching that happens over there. > What's even more unfortunate, is that JcrValueMap is implementing caching via > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/6e13f4d315ddf2804d2e16c55faee18e805b618e/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java#L49 > . That caching is not leveraged properly, because every call to getValueMap > returns a new JcrValueMap, instead of reusing a previously created one. > One change that can be done is maybe converting the logic inside the > adaptTo()-method to a dedicated AdapterFactory implementation, so that > caching is done by default? -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] SLING-12052: add Pagefind for site search [sling-site]
bdelacretaz merged PR #133: URL: https://github.com/apache/sling-site/pull/133 -- 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] [Commented] (SLING-10899) Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached
[ https://issues.apache.org/jira/browse/SLING-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770994#comment-17770994 ] Carsten Ziegeler commented on SLING-10899: -- I looked at some other resource implementations and there the value map is actually cached inside the resource object. maybe it is ok to make this change and cache the value map within the resource and always return the same. > Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached > -- > > Key: SLING-10899 > URL: https://issues.apache.org/jira/browse/SLING-10899 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 3.0.22 >Reporter: Henry Kuijpers >Priority: Major > > I was performance testing our application. There is a specific part of the > code where we have a set of ~500 resources and we sort them based on a few > properties of the resources. Multiple properties are used (which results in > multiple calls to getValueMap). The sorting is done using a comparator, so > the logic that determines the order is accessed numerous times. > We've seen quite a decrease in performance when doing this with Resources > that are of type JcrNodeResource. Turns out that the result of getValueMap > (or adaptTo((Value)Map.class)) is not cached. > As you can see in the adaptTo()-method implementation: > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L136 > this call bypasses the AdapterFactory framework and also bypasses any > caching that happens over there. > What's even more unfortunate, is that JcrValueMap is implementing caching via > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/6e13f4d315ddf2804d2e16c55faee18e805b618e/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java#L49 > . That caching is not leveraged properly, because every call to getValueMap > returns a new JcrValueMap, instead of reusing a previously created one. > One change that can be done is maybe converting the logic inside the > adaptTo()-method to a dedicated AdapterFactory implementation, so that > caching is done by default? -- This message was sent by Atlassian Jira (v8.20.10#820010)
