[jira] [Commented] (SLING-8786) Expose thread pool metrics
[ https://issues.apache.org/jira/browse/SLING-8786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958861#comment-16958861 ] Krystian Nowak commented on SLING-8786: --- Thanks [~rombert]! Commit resolving this issue: [https://github.com/apache/sling-org-apache-sling-commons-threads/commit/55eda79e79271bf6a3a61286c74843d3753c2798] > Expose thread pool metrics > -- > > Key: SLING-8786 > URL: https://issues.apache.org/jira/browse/SLING-8786 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Threads 3.2.18 >Reporter: Krystian Nowak >Priority: Major > Fix For: Commons Threads 3.2.20 > > Attachments: SLING-8786.diff, ThreadPoolMetricsGauges.java > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Thread pool metrics exposed via [Sling Commons > Metrics|https://github.com/apache/sling-org-apache-sling-commons-metrics] > would be helpful e.g. to identify thread pool exhaustion and being able to > measure e.g. > [ExecutorActiveCount|https://github.com/apache/sling-org-apache-sling-commons-threads/blob/master/src/main/java/org/apache/sling/commons/threads/impl/ThreadPoolMBeanImpl.java#L40-L47] > (most likely as a > [gauge|https://sling.apache.org/apidocs/sling11/org/apache/sling/commons/metrics/Gauge.html]) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-8786) Expose thread pool metrics
[ https://issues.apache.org/jira/browse/SLING-8786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954561#comment-16954561 ] Krystian Nowak commented on SLING-8786: --- PR: [https://github.com/apache/sling-org-apache-sling-commons-threads/pull/1] > Expose thread pool metrics > -- > > Key: SLING-8786 > URL: https://issues.apache.org/jira/browse/SLING-8786 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Threads 3.2.18 >Reporter: Krystian Nowak >Priority: Major > Fix For: Commons Threads 3.2.20 > > Attachments: SLING-8786.diff, ThreadPoolMetricsGauges.java > > Time Spent: 10m > Remaining Estimate: 0h > > Thread pool metrics exposed via [Sling Commons > Metrics|https://github.com/apache/sling-org-apache-sling-commons-metrics] > would be helpful e.g. to identify thread pool exhaustion and being able to > measure e.g. > [ExecutorActiveCount|https://github.com/apache/sling-org-apache-sling-commons-threads/blob/master/src/main/java/org/apache/sling/commons/threads/impl/ThreadPoolMBeanImpl.java#L40-L47] > (most likely as a > [gauge|https://sling.apache.org/apidocs/sling11/org/apache/sling/commons/metrics/Gauge.html]) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-8786) Expose thread pool metrics
[ https://issues.apache.org/jira/browse/SLING-8786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krystian Nowak updated SLING-8786: -- Description: Thread pool metrics exposed via [Sling Commons Metrics|https://github.com/apache/sling-org-apache-sling-commons-metrics] would be helpful e.g. to identify thread pool exhaustion and being able to measure e.g. [ExecutorActiveCount|https://github.com/apache/sling-org-apache-sling-commons-threads/blob/master/src/main/java/org/apache/sling/commons/threads/impl/ThreadPoolMBeanImpl.java#L40-L47] (most likely as a [gauge|https://sling.apache.org/apidocs/sling11/org/apache/sling/commons/metrics/Gauge.html]) (was: Thread pool metrics exposed via [Sling Commons Metrics|https://github.com/apache/sling-org-apache-sling-commons-metrics] would be helpful e.g. to identify thread pool exhaustion and being able to measure e.g. ExecutorActiveCount (most likely as a [gauge|https://sling.apache.org/apidocs/sling11/org/apache/sling/commons/metrics/Gauge.html])) > Expose thread pool metrics > -- > > Key: SLING-8786 > URL: https://issues.apache.org/jira/browse/SLING-8786 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Threads 3.2.18 >Reporter: Krystian Nowak >Priority: Major > Fix For: Commons Threads 3.2.20 > > Attachments: SLING-8786.diff, ThreadPoolMetricsGauges.java > > > Thread pool metrics exposed via [Sling Commons > Metrics|https://github.com/apache/sling-org-apache-sling-commons-metrics] > would be helpful e.g. to identify thread pool exhaustion and being able to > measure e.g. > [ExecutorActiveCount|https://github.com/apache/sling-org-apache-sling-commons-threads/blob/master/src/main/java/org/apache/sling/commons/threads/impl/ThreadPoolMBeanImpl.java#L40-L47] > (most likely as a > [gauge|https://sling.apache.org/apidocs/sling11/org/apache/sling/commons/metrics/Gauge.html]) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-8786) Expose thread pool metrics
[ https://issues.apache.org/jira/browse/SLING-8786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krystian Nowak updated SLING-8786: -- Description: Thread pool metrics exposed via [Sling Commons Metrics|https://github.com/apache/sling-org-apache-sling-commons-metrics] would be helpful e.g. to identify thread pool exhaustion and being able to measure e.g. ExecutorActiveCount (most likely as a [gauge|https://sling.apache.org/apidocs/sling11/org/apache/sling/commons/metrics/Gauge.html]) (was: Thread pool metrics exposed via [Sling Commons Metrics|https://github.com/apache/sling-org-apache-sling-commons-metrics] would be helpful e.g. to identify thread pool exhaustion and being able to measure e.g. ExecutorActiveCount) > Expose thread pool metrics > -- > > Key: SLING-8786 > URL: https://issues.apache.org/jira/browse/SLING-8786 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Threads 3.2.18 >Reporter: Krystian Nowak >Priority: Major > Fix For: Commons Threads 3.2.20 > > Attachments: SLING-8786.diff, ThreadPoolMetricsGauges.java > > > Thread pool metrics exposed via [Sling Commons > Metrics|https://github.com/apache/sling-org-apache-sling-commons-metrics] > would be helpful e.g. to identify thread pool exhaustion and being able to > measure e.g. ExecutorActiveCount (most likely as a > [gauge|https://sling.apache.org/apidocs/sling11/org/apache/sling/commons/metrics/Gauge.html]) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-8786) Expose thread pool metrics
[ https://issues.apache.org/jira/browse/SLING-8786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krystian Nowak updated SLING-8786: -- Description: Thread pool metrics exposed via [Sling Commons Metrics|https://github.com/apache/sling-org-apache-sling-commons-metrics] would be helpful e.g. to identify thread pool exhaustion and being able to measure e.g. ExecutorActiveCount (was: Thread pool metrics exposed via Sling Commons Metrics would be helpful e.g. to identify thread pool exhaustion and being able to measure e.g. ExecutorActiveCount) > Expose thread pool metrics > -- > > Key: SLING-8786 > URL: https://issues.apache.org/jira/browse/SLING-8786 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Threads 3.2.18 >Reporter: Krystian Nowak >Priority: Major > Fix For: Commons Threads 3.2.20 > > Attachments: SLING-8786.diff, ThreadPoolMetricsGauges.java > > > Thread pool metrics exposed via [Sling Commons > Metrics|https://github.com/apache/sling-org-apache-sling-commons-metrics] > would be helpful e.g. to identify thread pool exhaustion and being able to > measure e.g. ExecutorActiveCount -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-8786) Expose thread pool metrics
[ https://issues.apache.org/jira/browse/SLING-8786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krystian Nowak updated SLING-8786: -- Attachment: ThreadPoolMetricsGauges.java > Expose thread pool metrics > -- > > Key: SLING-8786 > URL: https://issues.apache.org/jira/browse/SLING-8786 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Threads 3.2.18 >Reporter: Krystian Nowak >Priority: Major > Fix For: Commons Threads 3.2.20 > > Attachments: SLING-8786.diff, ThreadPoolMetricsGauges.java > > > Thread pool metrics exposed via Sling Commons Metrics would be helpful e.g. > to identify thread pool exhaustion and being able to measure e.g. > ExecutorActiveCount -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SLING-8786) Expose thread pool metrics
[ https://issues.apache.org/jira/browse/SLING-8786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krystian Nowak updated SLING-8786: -- Attachment: SLING-8786.diff > Expose thread pool metrics > -- > > Key: SLING-8786 > URL: https://issues.apache.org/jira/browse/SLING-8786 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Threads 3.2.18 >Reporter: Krystian Nowak >Priority: Major > Fix For: Commons Threads 3.2.20 > > Attachments: SLING-8786.diff, ThreadPoolMetricsGauges.java > > > Thread pool metrics exposed via Sling Commons Metrics would be helpful e.g. > to identify thread pool exhaustion and being able to measure e.g. > ExecutorActiveCount -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-8786) Expose thread pool metrics
Krystian Nowak created SLING-8786: - Summary: Expose thread pool metrics Key: SLING-8786 URL: https://issues.apache.org/jira/browse/SLING-8786 Project: Sling Issue Type: Improvement Components: Commons Affects Versions: Commons Threads 3.2.18 Reporter: Krystian Nowak Fix For: Commons Threads 3.2.20 Thread pool metrics exposed via Sling Commons Metrics would be helpful e.g. to identify thread pool exhaustion and being able to measure e.g. ExecutorActiveCount -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-8682) IT apis-jar-wrapped-flattened-classes fails
[ https://issues.apache.org/jira/browse/SLING-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925919#comment-16925919 ] Krystian Nowak commented on SLING-8682: --- [~cziegeler]: PR is merge by [~simone.tripodi] - thanks! This ticket can be therefore mark as resolved and ready for 1.1.2 release. > IT apis-jar-wrapped-flattened-classes fails > --- > > Key: SLING-8682 > URL: https://issues.apache.org/jira/browse/SLING-8682 > Project: Sling > Issue Type: Bug > Components: Maven Plugins and Archetypes >Reporter: Carsten Ziegeler >Priority: Major > Fix For: slingfeature-maven-plugin 1.1.2 > > Time Spent: 20m > Remaining Estimate: 0h > > With the correction of subpackage handling in SLING-8681 the > apis-jar-wrapped-flattened-classes fails now. > This might be a bug in our api handling code as the javadoc command does not > get a source -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (SLING-8682) IT apis-jar-wrapped-flattened-classes fails
[ https://issues.apache.org/jira/browse/SLING-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925635#comment-16925635 ] Krystian Nowak commented on SLING-8682: --- [~cziegeler], [~simone.tripodi] - it turned out that the Java package in apis-jar-wrapped-flattened-classes IT API region exports was in fact not existing in bundle's sources jar making the directory empty and exposing the edge case (which was explicitly visible in Java 9+, here Java 11, but not obviously visible in Java 8 without going into wrapped IT Maven subprojects). Please have a look at this PR for IT test config fix and protection against such edge case in MOJO: [https://github.com/apache/sling-slingfeature-maven-plugin/pull/38] > IT apis-jar-wrapped-flattened-classes fails > --- > > Key: SLING-8682 > URL: https://issues.apache.org/jira/browse/SLING-8682 > Project: Sling > Issue Type: Bug > Components: Maven Plugins and Archetypes >Reporter: Carsten Ziegeler >Priority: Major > Fix For: slingfeature-maven-plugin 1.1.2 > > Time Spent: 10m > Remaining Estimate: 0h > > With the correction of subpackage handling in SLING-8681 the > apis-jar-wrapped-flattened-classes fails now. > This might be a bug in our api handling code as the javadoc command does not > get a source -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (SLING-8682) IT apis-jar-wrapped-flattened-classes fails
[
https://issues.apache.org/jira/browse/SLING-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925470#comment-16925470
]
Krystian Nowak edited comment on SLING-8682 at 9/9/19 9:05 AM:
---
[~cziegeler]: Isn't it the case that when sourcesDir is empty, no javadoc at
all should be generated anyway? I was checking what happens in IT
apis-jar-wrapped-flattened-classes in both Java 8 and Java 11 case.
Even though in Java 8 it seems fine from outside:
{noformat}
docker volume create --name maven-repo
{noformat}
{noformat}
docker run -it --rm --name my-maven-project -v maven-repo:/root/.m2 -v
"$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.6.1-jdk-8 mvn clean
install
{noformat}
pretends to work OK:
{noformat}
[INFO] Building: apis-jar-wrapped-flattened-classes/pom.xml
[INFO] run post-build script verify.bsh
[INFO] apis-jar-wrapped-flattened-classes/pom.xml ... SUCCESS
(92.2 s)
{noformat}
(...)
{noformat}
[INFO] BUILD SUCCESS
{noformat}
*BUT* when changing the directory:
{noformat}
cd target/it/apis-jar-wrapped-flattened-classes
{noformat}
and running:
{noformat}
docker run -it --rm --name my-maven-project -v maven-repo:/root/.m2 -v
"$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.6.1-jdk-8 mvn clean
install
{noformat}
we get:
{noformat}
[INFO] --- slingfeature-maven-plugin:1.1.1-SNAPSHOT:apis-jar (analyze) @
slingfeature-maven-plugin-test ---
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-apis.jar
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-sources.jar
[INFO] Executing javadoc tool: [/usr/local/openjdk-8/jre/../bin/javadoc,
@/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test/base/base-javadoc]
[INFO]
javadoc: error - No packages or classes specified.
{noformat}
(...)
{noformat}
1 error
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-javadoc.jar
{noformat}
(...)
{noformat}
[INFO] BUILD SUCCESS
{noformat}
In Java 11 instead:
{noformat}
docker run -it --rm --name my-maven-project -v maven-repo:/root/.m2 -v
"$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.6.1-jdk-11 mvn clean
install
{noformat}
results in expliticly failed IT:
{noformat}
[INFO] Building: apis-jar-wrapped-flattened-classes/pom.xml
[INFO] run post-build script verify.bsh
[INFO] apis-jar-wrapped-flattened-classes/pom.xml ... FAILED
(88.2 s)
[INFO] The build exited with code 1. See
/usr/src/mymaven/target/it/apis-jar-wrapped-flattened-classes/build.log for
details.
{noformat}
resulting in:
{noformat}
[INFO] -
[INFO] Build Summary:
[INFO] Passed: 7, Failed: 1, Errors: 0, Skipped: 0
[INFO] -
[ERROR] The following builds failed:
[ERROR] * apis-jar-wrapped-flattened-classes/pom.xml
{noformat}
and
{noformat}
[INFO] BUILD FAILURE
{noformat}
Also diving into the specific directory:
{noformat}
cd target/it/apis-jar-wrapped-flattened-classes
{noformat}
and running:
{noformat}
docker run -it --rm --name my-maven-project -v maven-repo:/root/.m2 -v
"$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.6.1-jdk-11 mvn clean
install
{noformat}
we get an explicit javadoc error (similar to the one in Java 8 case, but this
one fails the outer build, hence it was visible from outside):
{noformat}
[INFO] --- slingfeature-maven-plugin:1.1.1-SNAPSHOT:apis-jar (analyze) @
slingfeature-maven-plugin-test ---
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-apis.jar
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-sources.jar
[INFO] Executing javadoc tool: [/usr/local/openjdk-11/bin/javadoc,
@/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test/base/base-javadoc]
[INFO]
javadoc: error - No modules, packages or classes specified.
1 error
[INFO]
[INFO] BUILD FAILURE
[INFO]
{noformat}
So it seems in case when _sourcesDir_ list in
[https://github.com/apache/sling-slingfeature-maven-plugin/blob/master/src/main/java/org/apache/sling/feature/maven/mojos/ApisJarMojo.java#L258-L260]
is empty, both in Java 8 and Java 11 the _javadoc_ exec invocation fails, but
the failure is not propagated up in Java 8, only in Java 11 case, hence only
then it was visible from outside in SLING-8597 and the resulting
[https://github.com/apache/sling-slingfeature-maven-plugin/commit/23e848409876cfa35b0ec8669612d73351f4e2e3]
- possibly SLING-8681 could be extended into not calling _javadoc_ exec at all
if _sourcesDir_ list is empty. It would result in not having javadocs jar
[jira] [Commented] (SLING-8682) IT apis-jar-wrapped-flattened-classes fails
[
https://issues.apache.org/jira/browse/SLING-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925470#comment-16925470
]
Krystian Nowak commented on SLING-8682:
---
[~cziegeler]: Isn't it the case that when sourcesDir is empty, no javadoc at
all should be generated anyway? I was checking what happens in IT
apis-jar-wrapped-flattened-classes in both Java 8 and Java 11 case.
Even though in Java 8 it seems fine from outside:
{noformat}
docker volume create --name maven-repo
{noformat}
{noformat}
docker run -it --rm --name my-maven-project -v maven-repo:/root/.m2 -v
"$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.6.1-jdk-8 mvn clean
install
{noformat}
pretends to work OK:
{noformat}
[INFO] Building: apis-jar-wrapped-flattened-classes/pom.xml
[INFO] run post-build script verify.bsh
[INFO] apis-jar-wrapped-flattened-classes/pom.xml ... SUCCESS
(92.2 s)
{noformat}
(...)
{noformat}
[INFO] BUILD SUCCESS
{noformat}
*BUT* when changing the directory:
{noformat}
cat target/it/apis-jar-wrapped-flattened-classes
{noformat}
and running:
{noformat}
docker run -it --rm --name my-maven-project -v maven-repo:/root/.m2 -v
"$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.6.1-jdk-8 mvn clean
install
{noformat}
we get:
{noformat}
[INFO] --- slingfeature-maven-plugin:1.1.1-SNAPSHOT:apis-jar (analyze) @
slingfeature-maven-plugin-test ---
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-apis.jar
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-sources.jar
[INFO] Executing javadoc tool: [/usr/local/openjdk-8/jre/../bin/javadoc,
@/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test/base/base-javadoc]
[INFO]
javadoc: error - No packages or classes specified.
{noformat}
(...)
{noformat}
1 error
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-javadoc.jar
{noformat}
(...)
{noformat}
[INFO] BUILD SUCCESS
{noformat}
In Java 11 instead:
{noformat}
docker run -it --rm --name my-maven-project -v maven-repo:/root/.m2 -v
"$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.6.1-jdk-11 mvn clean
install
{noformat}
results in expliticly failed IT:
{noformat}
[INFO] Building: apis-jar-wrapped-flattened-classes/pom.xml
[INFO] run post-build script verify.bsh
[INFO] apis-jar-wrapped-flattened-classes/pom.xml ... FAILED
(88.2 s)
[INFO] The build exited with code 1. See
/usr/src/mymaven/target/it/apis-jar-wrapped-flattened-classes/build.log for
details.
{noformat}
resulting in:
{noformat}
[INFO] -
[INFO] Build Summary:
[INFO] Passed: 7, Failed: 1, Errors: 0, Skipped: 0
[INFO] -
[ERROR] The following builds failed:
[ERROR] * apis-jar-wrapped-flattened-classes/pom.xml
{noformat}
and
{noformat}
[INFO] BUILD FAILURE
{noformat}
Also diving into the specific directory:
{noformat}
cat target/it/apis-jar-wrapped-flattened-classes
{noformat}
and running:
{noformat}
docker run -it --rm --name my-maven-project -v maven-repo:/root/.m2 -v
"$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.6.1-jdk-11 mvn clean
install
{noformat}
we get an explicit javadoc error (similar to the one in Java 8 case, but this
one fails the outer build, hence it was visible from outside):
{noformat}
[INFO] --- slingfeature-maven-plugin:1.1.1-SNAPSHOT:apis-jar (analyze) @
slingfeature-maven-plugin-test ---
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-apis.jar
[INFO] Building jar:
/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test-1.0.0-SNAPSHOT-base-sources.jar
[INFO] Executing javadoc tool: [/usr/local/openjdk-11/bin/javadoc,
@/usr/src/mymaven/target/apis-jars/slingfeature-maven-plugin-test/base/base-javadoc]
[INFO]
javadoc: error - No modules, packages or classes specified.
1 error
[INFO]
[INFO] BUILD FAILURE
[INFO]
{noformat}
So it seems in case when _sourcesDir_ list in
https://github.com/apache/sling-slingfeature-maven-plugin/blob/master/src/main/java/org/apache/sling/feature/maven/mojos/ApisJarMojo.java#L258-L260
is empty, both in Java 8 and Java 11 the _javadoc_ exec invocation fails, but
the failure is not propagated up in Java 8, only in Java 11 case, hence only
then it was visible from outside in SLING-8597 and the resulting
[https://github.com/apache/sling-slingfeature-maven-plugin/commit/23e848409876cfa35b0ec8669612d73351f4e2e3]
- possibly SLING-8681 could be extended into not calling _javadoc_ exec at all
if _sourcesDir_ list is empty. It would result in not having javadocs jar
produced in this case, but the jar produced
[jira] [Commented] (SLING-8495) Make FSClassLoader its cache location root directory configurable
[ https://issues.apache.org/jira/browse/SLING-8495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865530#comment-16865530 ] Krystian Nowak commented on SLING-8495: --- [~karlpauls]: Proposed changes in this PR: [https://github.com/apache/sling-org-apache-sling-commons-fsclassloader/pull/1] > Make FSClassLoader its cache location root directory configurable > - > > Key: SLING-8495 > URL: https://issues.apache.org/jira/browse/SLING-8495 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: File System ClassLoader 1.0.10 >Reporter: Krystian Nowak >Assignee: Karl Pauls >Priority: Major > Fix For: File System ClassLoader 1.0.12 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently FSClassLoader's cache location is on the bundle persistent storage > area. > In cases when it would make more sense to externalize it to a different > location, file system cache location root directory needs to be configurable. > For that > [https://github.com/apache/sling-org-apache-sling-commons-fsclassloader/blob/master/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderProvider.java#L108] > needs to be made parametrized to have its "root" directory configurable. > Also: > * > [https://github.com/apache/sling-org-apache-sling-commons-fsclassloader/blob/master/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderWebConsole.java#L95] > * > [https://github.com/apache/sling-org-apache-sling-commons-fsclassloader/blob/master/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderMBeanImpl.java#L79] > * > [https://github.com/apache/sling-org-apache-sling-commons-fsclassloader/blob/master/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderMBeanImpl.java#L109] > should be changed accordingly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-8495) Make FSClassLoader its cache location root directory configurable
Krystian Nowak created SLING-8495: - Summary: Make FSClassLoader its cache location root directory configurable Key: SLING-8495 URL: https://issues.apache.org/jira/browse/SLING-8495 Project: Sling Issue Type: Improvement Components: Commons Affects Versions: File System ClassLoader 1.0.10 Reporter: Krystian Nowak Currently FSClassLoader's cache location is on the bundle persistent storage area. In cases when it would make more sense to externalize it to a different location, file system cache location root directory needs to be configurable. For that [https://github.com/apache/sling-org-apache-sling-commons-fsclassloader/blob/master/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderProvider.java#L108] needs to be made parametrized to have its "root" directory configurable. Also: * [https://github.com/apache/sling-org-apache-sling-commons-fsclassloader/blob/master/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderWebConsole.java#L95] * [https://github.com/apache/sling-org-apache-sling-commons-fsclassloader/blob/master/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderMBeanImpl.java#L79] * [https://github.com/apache/sling-org-apache-sling-commons-fsclassloader/blob/master/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderMBeanImpl.java#L109] should be changed accordingly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-7526) NPE in DefaultThreadPool$LoggingThreadLocalChangeListener.changed
Krystian Nowak created SLING-7526:
-
Summary: NPE in
DefaultThreadPool$LoggingThreadLocalChangeListener.changed
Key: SLING-7526
URL: https://issues.apache.org/jira/browse/SLING-7526
Project: Sling
Issue Type: Bug
Components: Commons
Affects Versions: Commons Threads 3.2.16
Environment: MacOS, jdk18
Reporter: Krystian Nowak
Randomly a NullPointerException is happening in
_DefaultThreadPool$LoggingThreadLocalChangeListener.changed_:
{noformat}
Exception in thread "sling-oak-1" java.lang.NullPointerException
at
org.apache.sling.commons.threads.impl.DefaultThreadPool$LoggingThreadLocalChangeListener.changed(DefaultThreadPool.java:172)
at
org.apache.sling.commons.threads.impl.ThreadLocalCleaner.changed(ThreadLocalCleaner.java:210)
at
org.apache.sling.commons.threads.impl.ThreadLocalCleaner.diff(ThreadLocalCleaner.java:173)
at
org.apache.sling.commons.threads.impl.ThreadLocalCleaner.cleanup(ThreadLocalCleaner.java:148)
at
org.apache.sling.commons.threads.impl.ThreadPoolExecutorCleaningThreadLocals.afterExecute(ThreadPoolExecutorCleaningThreadLocals.java:75)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SLING-6457) MergedResource's toString does not display properly merged resources' paths
[
https://issues.apache.org/jira/browse/SLING-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Krystian Nowak closed SLING-6457.
-
[~kwin] You're welcome and thanks for applying it!
> MergedResource's toString does not display properly merged resources' paths
> ---
>
> Key: SLING-6457
> URL: https://issues.apache.org/jira/browse/SLING-6457
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Resource Merger 1.3.0
>Reporter: Krystian Nowak
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: Resource Merger 1.3.2
>
> Attachments: SLING-6457-krystian.patch
>
>
> Paths of merged resources are kept in a String array which is accessed by
> _toString_ via _ResourceMetadata metadata_ field which is in fact a String to
> Object map.
> Therefore _toString_ method prints
> _this.metadata.get(MergedResourceConstants.METADATA_RESOURCES)_ directly
> which results in an output similar to this:
> {noformat}
> MergedResource [path=/merged, resources=[Ljava.lang.String;@51920d25]
> {noformat}
> instead of e.g.:
> {noformat}
> MergedResource [path=/merged, resources=[/a, /b, /c]]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-6457) MergedResource's toString does not display properly merged resources' paths
[
https://issues.apache.org/jira/browse/SLING-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Krystian Nowak updated SLING-6457:
--
Attachment: SLING-6457-krystian.patch
Patch with a proposed fix attached
> MergedResource's toString does not display properly merged resources' paths
> ---
>
> Key: SLING-6457
> URL: https://issues.apache.org/jira/browse/SLING-6457
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Resource Merger 1.3.0
>Reporter: Krystian Nowak
>Priority: Minor
> Attachments: SLING-6457-krystian.patch
>
>
> Paths of merged resources are kept in a String array which is accessed by
> _toString_ via _ResourceMetadata metadata_ field which is in fact a String to
> Object map.
> Therefore _toString_ method prints
> _this.metadata.get(MergedResourceConstants.METADATA_RESOURCES)_ directly
> which results in an output similar to this:
> {noformat}
> MergedResource [path=/merged, resources=[Ljava.lang.String;@51920d25]
> {noformat}
> instead of e.g.:
> {noformat}
> MergedResource [path=/merged, resources=[/a, /b, /c]]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-6457) MergedResource's toString does not display properly merged resources' paths
Krystian Nowak created SLING-6457:
-
Summary: MergedResource's toString does not display properly
merged resources' paths
Key: SLING-6457
URL: https://issues.apache.org/jira/browse/SLING-6457
Project: Sling
Issue Type: Bug
Components: Extensions
Affects Versions: Resource Merger 1.3.0
Reporter: Krystian Nowak
Priority: Minor
Paths of merged resources are kept in a String array which is accessed by
_toString_ via _ResourceMetadata metadata_ field which is in fact a String to
Object map.
Therefore _toString_ method prints
_this.metadata.get(MergedResourceConstants.METADATA_RESOURCES)_ directly which
results in an output similar to this:
{noformat}
MergedResource [path=/merged, resources=[Ljava.lang.String;@51920d25]
{noformat}
instead of e.g.:
{noformat}
MergedResource [path=/merged, resources=[/a, /b, /c]]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6433) Request Processing Analyzer throws IOOB due to old format assumptions of RequestProgressTracker output
[
https://issues.apache.org/jira/browse/SLING-6433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15798062#comment-15798062
]
Krystian Nowak commented on SLING-6433:
---
The exception is thrown due to changes made in SLING-4114
> Request Processing Analyzer throws IOOB due to old format assumptions of
> RequestProgressTracker output
> --
>
> Key: SLING-6433
> URL: https://issues.apache.org/jira/browse/SLING-6433
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Reporter: Krystian Nowak
> Fix For: Request Analyzer 1.0.0
>
> Attachments: SLING-6433-krystian.patch
>
>
> In certain cases Request Processing Analyzer throws IndexOutOfBoundsException
> and fails to display request details:
> {noformat}
> Exception in thread "AWT-EventQueue-0"
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1931)
> at
> org.apache.sling.reqanalyzer.impl.gui.RequestTableModel.addRow(RequestTableModel.java:37)
> at
> org.apache.sling.reqanalyzer.impl.gui.RequestTrackerFile.getData(RequestTrackerFile.java:64)
> at
> org.apache.sling.reqanalyzer.impl.gui.RequestListSelectionListener.valueChanged(RequestListSelectionListener.java:65)
> at
> javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:184)
> at
> javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:154)
> at
> javax.swing.DefaultListSelectionModel.setValueIsAdjusting(DefaultListSelectionModel.java:685)
> at
> javax.swing.plaf.basic.BasicTableUI$Handler.setValueIsAdjusting(BasicTableUI.java:953)
> at
> javax.swing.plaf.basic.BasicTableUI$Handler.mouseReleased(BasicTableUI.java:1166)
> at
> javax.swing.plaf.basic.BasicTableUI$MouseInputHandler.mouseReleased(BasicTableUI.java:802)
> at
> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:290)
> at java.awt.Component.processMouseEvent(Component.java:6533)
> at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
> at java.awt.Component.processEvent(Component.java:6298)
> at java.awt.Container.processEvent(Container.java:2236)
> at java.awt.Component.dispatchEventImpl(Component.java:4889)
> at java.awt.Container.dispatchEventImpl(Container.java:2294)
> at java.awt.Component.dispatchEvent(Component.java:4711)
> at
> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
> at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)
> at java.awt.Container.dispatchEventImpl(Container.java:2280)
> at java.awt.Window.dispatchEventImpl(Window.java:2746)
> at java.awt.Component.dispatchEvent(Component.java:4711)
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
> at java.awt.EventQueue.access$500(EventQueue.java:97)
> at java.awt.EventQueue$3.run(EventQueue.java:709)
> at java.awt.EventQueue$3.run(EventQueue.java:703)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
> at
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
> at java.awt.EventQueue$4.run(EventQueue.java:731)
> at java.awt.EventQueue$4.run(EventQueue.java:729)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
> at
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
> at
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
> at
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
> {noformat}
> This is due to an old (pre-SLING-4114) assumptions on RequestProgressTracker
> output.
> SLING-4114 removed date and time fields which were ending in closing
> parenthesis but the analyzer is still looking for it while calculating string
> index. In most of the cases the request details are just wrongly displayed,
> but when the closing parenthesis character is at the end of the string then
> the index exceeds
[jira] [Updated] (SLING-6433) Request Processing Analyzer throws IOOB due to old format assumptions of RequestProgressTracker output
[
https://issues.apache.org/jira/browse/SLING-6433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Krystian Nowak updated SLING-6433:
--
Attachment: SLING-6433-krystian.patch
Patch attached
> Request Processing Analyzer throws IOOB due to old format assumptions of
> RequestProgressTracker output
> --
>
> Key: SLING-6433
> URL: https://issues.apache.org/jira/browse/SLING-6433
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Reporter: Krystian Nowak
> Fix For: Request Analyzer 1.0.0
>
> Attachments: SLING-6433-krystian.patch
>
>
> In certain cases Request Processing Analyzer throws IndexOutOfBoundsException
> and fails to display request details:
> {noformat}
> Exception in thread "AWT-EventQueue-0"
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1931)
> at
> org.apache.sling.reqanalyzer.impl.gui.RequestTableModel.addRow(RequestTableModel.java:37)
> at
> org.apache.sling.reqanalyzer.impl.gui.RequestTrackerFile.getData(RequestTrackerFile.java:64)
> at
> org.apache.sling.reqanalyzer.impl.gui.RequestListSelectionListener.valueChanged(RequestListSelectionListener.java:65)
> at
> javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:184)
> at
> javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:154)
> at
> javax.swing.DefaultListSelectionModel.setValueIsAdjusting(DefaultListSelectionModel.java:685)
> at
> javax.swing.plaf.basic.BasicTableUI$Handler.setValueIsAdjusting(BasicTableUI.java:953)
> at
> javax.swing.plaf.basic.BasicTableUI$Handler.mouseReleased(BasicTableUI.java:1166)
> at
> javax.swing.plaf.basic.BasicTableUI$MouseInputHandler.mouseReleased(BasicTableUI.java:802)
> at
> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:290)
> at java.awt.Component.processMouseEvent(Component.java:6533)
> at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
> at java.awt.Component.processEvent(Component.java:6298)
> at java.awt.Container.processEvent(Container.java:2236)
> at java.awt.Component.dispatchEventImpl(Component.java:4889)
> at java.awt.Container.dispatchEventImpl(Container.java:2294)
> at java.awt.Component.dispatchEvent(Component.java:4711)
> at
> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
> at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)
> at java.awt.Container.dispatchEventImpl(Container.java:2280)
> at java.awt.Window.dispatchEventImpl(Window.java:2746)
> at java.awt.Component.dispatchEvent(Component.java:4711)
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
> at java.awt.EventQueue.access$500(EventQueue.java:97)
> at java.awt.EventQueue$3.run(EventQueue.java:709)
> at java.awt.EventQueue$3.run(EventQueue.java:703)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
> at
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
> at java.awt.EventQueue$4.run(EventQueue.java:731)
> at java.awt.EventQueue$4.run(EventQueue.java:729)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
> at
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
> at
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
> at
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
> {noformat}
> This is due to an old (pre-SLING-4114) assumptions on RequestProgressTracker
> output.
> SLING-4114 removed date and time fields which were ending in closing
> parenthesis but the analyzer is still looking for it while calculating string
> index. In most of the cases the request details are just wrongly displayed,
> but when the closing parenthesis character is at the end of the string then
> the index exceeds string length resulting in the exception.
[jira] [Created] (SLING-6433) Request Processing Analyzer throws IOOB due to old format assumptions of RequestProgressTracker output
Krystian Nowak created SLING-6433:
-
Summary: Request Processing Analyzer throws IOOB due to old format
assumptions of RequestProgressTracker output
Key: SLING-6433
URL: https://issues.apache.org/jira/browse/SLING-6433
Project: Sling
Issue Type: Bug
Components: Extensions
Reporter: Krystian Nowak
Fix For: Request Analyzer 1.0.0
In certain cases Request Processing Analyzer throws IndexOutOfBoundsException
and fails to display request details:
{noformat}
Exception in thread "AWT-EventQueue-0"
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1931)
at
org.apache.sling.reqanalyzer.impl.gui.RequestTableModel.addRow(RequestTableModel.java:37)
at
org.apache.sling.reqanalyzer.impl.gui.RequestTrackerFile.getData(RequestTrackerFile.java:64)
at
org.apache.sling.reqanalyzer.impl.gui.RequestListSelectionListener.valueChanged(RequestListSelectionListener.java:65)
at
javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:184)
at
javax.swing.DefaultListSelectionModel.fireValueChanged(DefaultListSelectionModel.java:154)
at
javax.swing.DefaultListSelectionModel.setValueIsAdjusting(DefaultListSelectionModel.java:685)
at
javax.swing.plaf.basic.BasicTableUI$Handler.setValueIsAdjusting(BasicTableUI.java:953)
at
javax.swing.plaf.basic.BasicTableUI$Handler.mouseReleased(BasicTableUI.java:1166)
at
javax.swing.plaf.basic.BasicTableUI$MouseInputHandler.mouseReleased(BasicTableUI.java:802)
at
java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:290)
at java.awt.Component.processMouseEvent(Component.java:6533)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
at java.awt.Component.processEvent(Component.java:6298)
at java.awt.Container.processEvent(Container.java:2236)
at java.awt.Component.dispatchEventImpl(Component.java:4889)
at java.awt.Container.dispatchEventImpl(Container.java:2294)
at java.awt.Component.dispatchEvent(Component.java:4711)
at
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)
at java.awt.Container.dispatchEventImpl(Container.java:2280)
at java.awt.Window.dispatchEventImpl(Window.java:2746)
at java.awt.Component.dispatchEvent(Component.java:4711)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
at
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
at java.awt.EventQueue$4.run(EventQueue.java:731)
at java.awt.EventQueue$4.run(EventQueue.java:729)
at java.security.AccessController.doPrivileged(Native Method)
at
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
{noformat}
This is due to an old (pre-SLING-4114) assumptions on RequestProgressTracker
output.
SLING-4114 removed date and time fields which were ending in closing
parenthesis but the analyzer is still looking for it while calculating string
index. In most of the cases the request details are just wrongly displayed, but
when the closing parenthesis character is at the end of the string then the
index exceeds string length resulting in the exception. The solution is to
update the code to the current RequestProgressTracker output format without
those removed fields.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
