[jira] [Updated] (SLING-12301) Improve error handling during registration of ServletContext
[ https://issues.apache.org/jira/browse/SLING-12301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Hoh updated SLING-12301: -- Description: With SLING-11824 the registration of the ServletContext objects was made asynchronous using bare Threads. If this process fails with any exception, the thread just dies because there is no explicit exception handling and not logging for that case. We should add some logging to have at least traces if such a problem occurs. was: With SLING-11824 the registration of the ServletContext objects was made asynchronous using bare Threads. If this process fails with any exception, the thread just dies because there is no explicit exception handling and not logging for that case. We should add to have at least traces if such a problem occurs. > Improve error handling during registration of ServletContext > > > Key: SLING-12301 > URL: https://issues.apache.org/jira/browse/SLING-12301 > Project: Sling > Issue Type: Task > Components: Engine >Affects Versions: Engine 2.15.10 >Reporter: Joerg Hoh >Priority: Major > > With SLING-11824 the registration of the ServletContext objects was made > asynchronous using bare Threads. > If this process fails with any exception, the thread just dies because there > is no explicit exception handling and not logging for that case. > We should add some logging to have at least traces if such a problem occurs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12301) Improve error handling during registration of ServletContext
[ https://issues.apache.org/jira/browse/SLING-12301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Hoh updated SLING-12301: -- Description: With SLING-11824 the registration of the ServletContext objects was made asynchronous using bare Threads. If this process fails with any exception, the thread just dies because there is no explicit exception handling and not logging for that case. We should add some logging to have at least traces that such a problem occurred. was: With SLING-11824 the registration of the ServletContext objects was made asynchronous using bare Threads. If this process fails with any exception, the thread just dies because there is no explicit exception handling and not logging for that case. We should add some logging to have at least traces if such a problem occurs. > Improve error handling during registration of ServletContext > > > Key: SLING-12301 > URL: https://issues.apache.org/jira/browse/SLING-12301 > Project: Sling > Issue Type: Task > Components: Engine >Affects Versions: Engine 2.15.10 >Reporter: Joerg Hoh >Priority: Major > > With SLING-11824 the registration of the ServletContext objects was made > asynchronous using bare Threads. > If this process fails with any exception, the thread just dies because there > is no explicit exception handling and not logging for that case. > We should add some logging to have at least traces that such a problem > occurred. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12301) Improve error handling during registration of ServletContext
Joerg Hoh created SLING-12301: - Summary: Improve error handling during registration of ServletContext Key: SLING-12301 URL: https://issues.apache.org/jira/browse/SLING-12301 Project: Sling Issue Type: Task Components: Engine Affects Versions: Engine 2.15.10 Reporter: Joerg Hoh With SLING-11824 the registration of the ServletContext objects was made asynchronous using bare Threads. If this process fails with any exception, the thread just dies because there is no explicit exception handling and not logging for that case. We should add to have at least traces if such a problem occurs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert closed SLING-12278.
--
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Assignee: Stefan Seifert
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] SLING-12278 sling-mock/osgi-mock Documentation: Clarify not to use @BeforeAll and not to instantiate context within @BeforeEach methods [sling-site]
stefanseifert merged PR #159: URL: https://github.com/apache/sling-site/pull/159 -- 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] [Resolved] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-12278.
Resolution: Fixed
https://github.com/apache/sling-site/commit/5c122e825c6cf212e74fadeb2e6cc2afce0666a8
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert reassigned SLING-12278:
--
Assignee: Stefan Seifert
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Assignee: Stefan Seifert
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] SLING-12278 sling-mock/osgi-mock Documentation: Clarify not to use @BeforeAll and not to instantiate context within @BeforeEach methods [sling-site]
kwin commented on PR #159: URL: https://github.com/apache/sling-site/pull/159#issuecomment-2069627616 Thanks for the clarification, looks good to me. -- 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-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839637#comment-17839637
]
Stefan Seifert commented on SLING-12278:
documentation PR: https://github.com/apache/sling-site/pull/159
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated SLING-12278:
---
Component/s: Testing
Affects Version/s: Testing Sling Mock 3.5.0
Testing OSGi Mock 3.4.2
the way the current junit 5 implemention is done in sling-mock, osgi-mock and
aem-mock dates back to the time of JUnit 5.0 ([PR
#5|[https://github.com/wcm-io/wcm-io-testing/pull/5]),] and i've never
investigated much further if this is nowadays still the best way to do an junit
5 extension. it seems the programmatic extension registration was introduced in
junit 5.1.
i currently cannot oversee how much benefit a switch or additional support of
programmatic extension registration would bring - in any case it would be a lot
of work to make sure it all works as expected, and we cannot remove the current
way to register it for backwards compatibility.
so for now, i will only extend the documentation to make sure context objects
are not created e.g. in BeforeEach/BeforeAll methods.
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839626#comment-17839626
]
Stefan Seifert edited comment on SLING-12278 at 4/22/24 11:51 AM:
--
the way the current junit 5 implemention is done in sling-mock, osgi-mock and
aem-mock dates back to the time of JUnit 5.0 ([PR
#5|https://github.com/wcm-io/wcm-io-testing/pull/5]), and i've never
investigated much further if this is nowadays still the best way to do an junit
5 extension. it seems the programmatic extension registration was introduced in
junit 5.1.
i currently cannot oversee how much benefit a switch or additional support of
programmatic extension registration would bring - in any case it would be a lot
of work to make sure it all works as expected, and we cannot remove the current
way to register it for backwards compatibility.
so for now, i will only extend the documentation to make sure context objects
are not created e.g. in BeforeEach/BeforeAll methods.
was (Author: sseif...@pro-vision.de):
the way the current junit 5 implemention is done in sling-mock, osgi-mock and
aem-mock dates back to the time of JUnit 5.0 ([PR
#5|[https://github.com/wcm-io/wcm-io-testing/pull/5]),] and i've never
investigated much further if this is nowadays still the best way to do an junit
5 extension. it seems the programmatic extension registration was introduced in
junit 5.1.
i currently cannot oversee how much benefit a switch or additional support of
programmatic extension registration would bring - in any case it would be a lot
of work to make sure it all works as expected, and we cannot remove the current
way to register it for backwards compatibility.
so for now, i will only extend the documentation to make sure context objects
are not created e.g. in BeforeEach/BeforeAll methods.
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
RE: [VOTE] Sling Engine 2.15.14
+1 stefan
Re: [PR] SLING-11906 Migrate to slf4j 2.x [sling-org-apache-sling-commons-log]
rombert commented on code in PR #18:
URL:
https://github.com/apache/sling-org-apache-sling-commons-log/pull/18#discussion_r1574507607
##
src/main/java/ch/qos/logback/classic/PatternLayoutOsgi.java:
##
@@ -0,0 +1,183 @@
+/**
+ * Logback: the reliable, generic, fast and flexible logging framework.
+ * Copyright (C) 1999-2015, QOS.ch. All rights reserved.
+ *
+ * This program and the accompanying materials are dual-licensed under
+ * either the terms of the Eclipse Public License v1.0 as published by
+ * the Eclipse Foundation
+ *
+ * or (per the licensee's choosing)
+ *
+ * under the terms of the GNU Lesser General Public License version 2.1
+ * as published by the Free Software Foundation.
+ */
+package ch.qos.logback.classic;
+
+import java.util.HashMap;
+import java.util.Map;
+
+import ch.qos.logback.classic.pattern.*;
Review Comment:
@rishabhdaim - thanks for reviewing this PR. IIUC, @enapps-enorman has
'vendored'/copied over code from a third party library. If we decide to go this
way I think we should keep it unchanged, deviations make it hard to compare
with upstream and resync with later versions, if needed.
##
src/main/java/ch/qos/logback/classic/PatternLayoutOsgi.java:
##
@@ -0,0 +1,183 @@
+/**
+ * Logback: the reliable, generic, fast and flexible logging framework.
+ * Copyright (C) 1999-2015, QOS.ch. All rights reserved.
+ *
+ * This program and the accompanying materials are dual-licensed under
+ * either the terms of the Eclipse Public License v1.0 as published by
+ * the Eclipse Foundation
+ *
+ * or (per the licensee's choosing)
+ *
+ * under the terms of the GNU Lesser General Public License version 2.1
+ * as published by the Free Software Foundation.
+ */
+package ch.qos.logback.classic;
+
+import java.util.HashMap;
+import java.util.Map;
+
+import ch.qos.logback.classic.pattern.*;
+import ch.qos.logback.classic.pattern.color.HighlightingCompositeConverter;
+import ch.qos.logback.classic.spi.ILoggingEvent;
+import ch.qos.logback.core.CoreConstants;
+import ch.qos.logback.core.pattern.PatternLayoutBaseOsgi;
+import ch.qos.logback.core.pattern.color.*;
+import ch.qos.logback.core.pattern.parser.Parser;
+
+/**
+ *
+ * A flexible layout configurable with pattern string. The goal of this class
is
+ * to {@link #format format} a {@link ILoggingEvent} and return the results in
a
+ * {#link String}. The format of the result depends on the conversion
+ * pattern.
+ *
+ * For more information about this layout, please refer to the online manual at
+ * http://logback.qos.ch/manual/layouts.html#PatternLayout
+ *
+ */
+
+public class PatternLayoutOsgi extends PatternLayoutBaseOsgi {
+
+public static final Map DEFAULT_CONVERTER_MAP = new
HashMap<>();
Review Comment:
Same as
https://github.com/apache/sling-org-apache-sling-commons-log/pull/18#discussion_r1574507607
--
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] [Closed] (SLING-12287) sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release
[ https://issues.apache.org/jira/browse/SLING-12287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12287. -- > sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release > > > Key: SLING-12287 > URL: https://issues.apache.org/jira/browse/SLING-12287 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock Oak 3.2.0-1.22.15, Testing Sling Mock > Oak 4.0.0-1.62.0 > > > following the discussion with [~reschke] in SLING-12266 we should move away > from oak 1.44 which is quite outdated. however, we need to ensure to keep > compatibility with the old 1.22.x version range to support all sorts of > projects using the mocks. > a solution might be to switch to a recent version of oak in the POM, and > create dedicated ITs to test against this and older 1.22.x versions to ensure > compatibility. > the benefit is, that all projects that are "just using" sling-mock-oak > without thinking about the dependency management (e.g. not using something > like [https://wcm.io/tooling/maven/aem-dependencies.html)] will get the > latest version which is better supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12266) Cache initial repository state to improve JCR_OAK performance
[ https://issues.apache.org/jira/browse/SLING-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12266. -- > Cache initial repository state to improve JCR_OAK performance > - > > Key: SLING-12266 > URL: https://issues.apache.org/jira/browse/SLING-12266 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Assignee: Stefan Seifert >Priority: Minor > Fix For: Testing Sling Mock Oak 3.2.0-1.22.15, Testing Sling Mock > 3.5.0, Testing Sling Mock Oak 4.0.0-1.62.0 > > > A lot of effort goes into preparing an Oak Mock repository from scratch: node > types need to be registered, indexes need to be created, and all this happens > over several commits. None of this work depends on the test case itself, so > it will always result in the exact same repository state. We could take the > root NodeState from the first repository we build, then build subsequent > repositories on top of it, avoiding most of the redundant work. Commits can > be relatively expensive even in memory, so each one we avoid can save a lot > of time in the long term. > > This would require extending the contract between Testing Sling Mock and the > ResourceResolverTypeAdapters, to add optional "make snapshot" and "build repo > from snapshot" operations. For adapters that don't support them, we would > keep rebuilding things from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12265) Node type registration is inefficient during unit tests when using the JCR_OAK resolver type
[ https://issues.apache.org/jira/browse/SLING-12265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12265. -- > Node type registration is inefficient during unit tests when using the > JCR_OAK resolver type > > > Key: SLING-12265 > URL: https://issues.apache.org/jira/browse/SLING-12265 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Assignee: Stefan Seifert >Priority: Minor > Labels: performance > Fix For: Testing Sling Mock 3.5.0 > > > I did some profiling on my company's slow-running unit tests today, and found > that 70+% of the CPU time is spent inside NodeTypeDefinitionScanner, more > specifically in the commit() call triggered by it. Our test classpath > includes AEM Mocks and the Cloud SDK, resulting in 30+ CND files being > detected, and as many commits done preparing the repository before each test. > (Slightly more, because some commits fail and get retried later.) > It should be possible to parse each CND into memory structures in a separate > pass, then create the node types all at once in a single commit. This > wouldn't just eliminate the extra commits, but would also remove the need to > retry, since all dependencies would also be provided in the same call. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12296) sling-mock-oak: Update to Oak 1.62.0
[ https://issues.apache.org/jira/browse/SLING-12296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12296. -- > sling-mock-oak: Update to Oak 1.62.0 > > > Key: SLING-12296 > URL: https://issues.apache.org/jira/browse/SLING-12296 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Minor > Fix For: Testing Sling Mock Oak 4.0.0-1.62.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12284) sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12284. -- > sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum > Version > -- > > Key: SLING-12284 > URL: https://issues.apache.org/jira/browse/SLING-12284 > Project: Sling > Issue Type: Improvement > Components: Testing >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Logging Mock 2.1.0, Testing Sling Mock Oak > 3.2.0-1.22.15, Context-Aware Configuration Mock Plugin 1.6.0, Testing JCR > Mock 1.7.0, Testing OSGi Mock 3.5.0, Testing ResourceResolver Mock 1.5.0, > Testing Sling Mock 3.5.0, Testing Sling Mock Oak 4.0.0-1.62.0 > > > update to parent 60, see also [https://cwiki.apache.org/confluence/x/SI75E] > this drops java 8 support, and instead supports java 11, 17, 21 - build is > done with java 17 > minimum java requirement for runtime is java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[RESULT] [VOTE] Release Apache Sling Testing Sling Mock Oak 3.2.0-1.22.15
Hi, The vote has passed with the following result : +1 (binding): Stefan Seifert, Jörg Hoh, Radu Cotescu, Robert Munteanu I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. stefan
[RESULT] [VOTE] Release Apache Sling Testing Sling Mock 3.5.0, Sling Mock Oak 4.0.0-1.62.0
Hi, The vote has passed with the following result : +1 (binding): Stefan Seifert, Jörg Hoh, Radu Cotescu, Robert Munteanu I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. stefan
Re: [PR] SLING-11906 Migrate to slf4j 2.x [sling-org-apache-sling-commons-log]
rishabhdaim commented on code in PR #18:
URL:
https://github.com/apache/sling-org-apache-sling-commons-log/pull/18#discussion_r1574314774
##
src/main/java/ch/qos/logback/classic/PatternLayoutOsgi.java:
##
@@ -0,0 +1,183 @@
+/**
+ * Logback: the reliable, generic, fast and flexible logging framework.
+ * Copyright (C) 1999-2015, QOS.ch. All rights reserved.
+ *
+ * This program and the accompanying materials are dual-licensed under
+ * either the terms of the Eclipse Public License v1.0 as published by
+ * the Eclipse Foundation
+ *
+ * or (per the licensee's choosing)
+ *
+ * under the terms of the GNU Lesser General Public License version 2.1
+ * as published by the Free Software Foundation.
+ */
+package ch.qos.logback.classic;
+
+import java.util.HashMap;
+import java.util.Map;
+
+import ch.qos.logback.classic.pattern.*;
+import ch.qos.logback.classic.pattern.color.HighlightingCompositeConverter;
+import ch.qos.logback.classic.spi.ILoggingEvent;
+import ch.qos.logback.core.CoreConstants;
+import ch.qos.logback.core.pattern.PatternLayoutBaseOsgi;
+import ch.qos.logback.core.pattern.color.*;
+import ch.qos.logback.core.pattern.parser.Parser;
+
+/**
+ *
+ * A flexible layout configurable with pattern string. The goal of this class
is
+ * to {@link #format format} a {@link ILoggingEvent} and return the results in
a
+ * {#link String}. The format of the result depends on the conversion
+ * pattern.
+ *
+ * For more information about this layout, please refer to the online manual at
+ * http://logback.qos.ch/manual/layouts.html#PatternLayout
+ *
+ */
+
+public class PatternLayoutOsgi extends PatternLayoutBaseOsgi {
+
+public static final Map DEFAULT_CONVERTER_MAP = new
HashMap<>();
Review Comment:
We should provide the estimated size to `HashMap` to avoid resizing.
##
src/main/java/ch/qos/logback/classic/PatternLayoutOsgi.java:
##
@@ -0,0 +1,183 @@
+/**
+ * Logback: the reliable, generic, fast and flexible logging framework.
+ * Copyright (C) 1999-2015, QOS.ch. All rights reserved.
+ *
+ * This program and the accompanying materials are dual-licensed under
+ * either the terms of the Eclipse Public License v1.0 as published by
+ * the Eclipse Foundation
+ *
+ * or (per the licensee's choosing)
+ *
+ * under the terms of the GNU Lesser General Public License version 2.1
+ * as published by the Free Software Foundation.
+ */
+package ch.qos.logback.classic;
+
+import java.util.HashMap;
+import java.util.Map;
+
+import ch.qos.logback.classic.pattern.*;
Review Comment:
I would avoid using `*` in imports
--
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] [Comment Edited] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839511#comment-17839511
]
Radu Cotescu edited comment on SLING-12300 at 4/22/24 7:01 AM:
---
[~enorman], nobody trivialised your concerns. I’m not sure if everyone is
familiarised with the UUIDv4 standard that Oak uses for the {{jcr:uuid}}
property and I was just trying to explain the problem space. In addition, you
expressed that there would be security issues by implementing this feature, but
didn’t explain which. Predictability is not a security concern IMO if you
correctly use ACLs.
[~paul.bjorkstrand], for my use-case I only need those resources addressable by
ID at the Java API level. The application that is built on top controls the URL
space, but I wanted to use the Sling API for accessing the resource tree. You
could ask why the contradiction: update the JCR resource provider to use a
feature exposed only by JCR, but consume it via Sling?! Well, the Sling API is
just easier to use and simpler to understand for developers than the JCR one.
Adding a new Resource Provider could also be an option, but in the end it would
perform the same function in the same way: it would offer a way to retrieve
resources by ID from its mount root, whichever that will be.
I also thought about extending the Sling Resource API, but given that right now
only one commonly used provider generates IDs for the resources it creates I
thought it would be too complex and not provide so many gains.
I will obviously not push something that the Sling community doesn’t agree
with, but I would like that we discuss the alternatives and pick the solution
that makes the most sense in terms of effort/benefits.
was (Author: radu.cotescu):
[~enorman], nobody trivialised your concerns. I’m not sure if everyone is
familiarised with the UUIDv4 standard that Oak uses for the {{jcr:uuid}}
property and I was just trying to explain the problem space. In addition, you
expressed that there would be security issues by implementing this feature, but
didn’t explain which. Predictability is not a security concern IMO if you
correctly use ACLs.
[~paul.bjorkstrand], for my use-case I only need those resources addressable by
ID at the Java API level. The application that is built on top controls the URL
space, but I wanted to use the Sling API for accessing the resource tree. You
could ask why the contradiction: update the JCR resource provider to use a
feature exposed only by JCR, but consume it via Sling?! Well, the Sling API is
just easier to use and simpler to understand for developers than the JCR one.
Adding a new Resource Provider could also be an option, but in the end it would
perform the same function in the same way: it would offer a way to retrieve
resources by ID from its mount root, whichever that will be.
I also thought about extending the Sling Resource API, but given that right now
only one commonly use provider generates IDs for the resources it creates I
thought it would be too complex and not provide so many gains.
I will obviously not push something that the Sling community doesn’t agree
with, but I would like that we discuss the alternatives and pick the solution
that makes the most sense in terms of effort/benefits.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839511#comment-17839511
]
Radu Cotescu commented on SLING-12300:
--
[~enorman], nobody trivialised your concerns. I’m not sure if everyone is
familiarised with the UUIDv4 standard that Oak uses for the {{jcr:uuid}}
property and I was just trying to explain the problem space. In addition, you
expressed that there would be security issues by implementing this feature, but
didn’t explain which. Predictability is not a security concern IMO if you
correctly use ACLs.
[~paul.bjorkstrand], for my use-case I only need those resources addressable by
ID at the Java API level. The application that is built on top controls the URL
space, but I wanted to use the Sling API for accessing the resource tree. You
could ask why the contradiction: update the JCR resource provider to use a
feature exposed only by JCR, but consume it via Sling?! Well, the Sling API is
just easier to use and simpler to understand for developers than the JCR one.
Adding a new Resource Provider could also be an option, but in the end it would
perform the same function in the same way: it would offer a way to retrieve
resources by ID from its mount root, whichever that will be.
I also thought about extending the Sling Resource API, but given that right now
only one commonly use provider generates IDs for the resources it creates I
thought it would be too complex and not provide so many gains.
I will obviously not push something that the Sling community doesn’t agree
with, but I would like that we discuss the alternatives and pick the solution
that makes the most sense in terms of effort/benefits.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
