[jira] [Commented] (SLING-2463) Sling Script Console Plugin
[ https://issues.apache.org/jira/browse/SLING-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488459#comment-16488459 ] Chetan Mehrotra commented on SLING-2463: [~bdelacretaz] Probably we can remove this module now as it now lives in Felix project http://felix.apache.org/documentation/subprojects/apache-felix-script-console-plugin.html > Sling Script Console Plugin > --- > > Key: SLING-2463 > URL: https://issues.apache.org/jira/browse/SLING-2463 > Project: Sling > Issue Type: New Feature > Components: Scripting >Reporter: Chetan Mehrotra >Assignee: Felix Meschberger >Priority: Minor > Attachments: script-console.patch > > > I have implemented a Felix WebConsole plugin for evaluating scripts making > use of existing infrastructure present in Sling. It provides support for > following items > * Support evaluation of script in any language as supported by Sling e.g. > Groovy, JavaScript, Ruby, Python etc. You would need to ensure that relevant > language bundle is deployed > * Code editor with syntax highlighting support based on CodeMirror Javascript > library > * Hot key support > * Execute remote testcase via evaluating test scripts > The code is pushed to my forked Git repo for Sling at [1]. Complete details > about the plugin (with screen shots) is provided at [2]. > Comments and feedback welcome!! > [1] https://github.com/chetanmeh/sling/tree/script-console > [2] https://github.com/chetanmeh/c/wiki/Sling-Script-Console -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-7660) LogManager configuration "Number of Log Files" limited to 20
[
https://issues.apache.org/jira/browse/SLING-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16473899#comment-16473899
]
Chetan Mehrotra commented on SLING-7660:
+1 to increase the size. Not sure on setting it to max. From
[LOGBACK-266|https://jira.qos.ch/browse/LOGBACK-266] it appears that limit has
some reasoning.
bq. It seems the limit is there, since for each roll, where maxIndex=N, there
are N file renames, and this doesn't scale well up to 100 renames. (Well
actually it depends on the filesystem)
>From the referred issue it appears that recommendation is to use
>[SizeAndTimeBasedFNATP|https://logback.qos.ch/manual/appenders.html#SizeAndTimeBasedFNATP]
> LogManager configuration "Number of Log Files" limited to 20
>
>
> Key: SLING-7660
> URL: https://issues.apache.org/jira/browse/SLING-7660
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Affects Versions: Commons Log 5.1.6
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: Commons Log 5.1.8
>
>
> The "Number of Log Files" configuration property for size-based log rotation
> is capped at 20 (or 21 including the current log file. This limitation comes
> from [logback's
> {{FixedWindowRollingPolicy}}|https://github.com/qos-ch/logback/blob/39c7ab9510c4f48ef3fcbef248aac380d3b58235/logback-core/src/main/java/ch/qos/logback/core/rolling/FixedWindowRollingPolicy.java#L47],
> but can be overridden in a subclass. I propose to override the
> {{FixedWindowRollingPolicy#getMaxWindowSize}} to return {{Integer.MAX_VALUE}}.
> cc [~chetanm]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-7583) Log tracer runs into ClassCastException for oak-queries
[
https://issues.apache.org/jira/browse/SLING-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16442108#comment-16442108
]
Chetan Mehrotra commented on SLING-7583:
{quote}I would propose to use {{String.valueOf()}} here to get the proper
{{toString()}} implementation of the {{QueryImpl}} object.
{quote}
+1. Fixed as per your suggestion in
[commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-tracer.git;a=commit;h=ee13d5caf8ef714bcd2ad51d4ae414ccfbb37946]
> Log tracer runs into ClassCastException for oak-queries
> ---
>
> Key: SLING-7583
> URL: https://issues.apache.org/jira/browse/SLING-7583
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Log Tracer 1.0.6, Log Tracer 1.0.4
>Reporter: Dirk Rudolph
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: Log Tracer 1.0.8
>
>
> Oak's {{QueryEngineImpl}} logs the following "cost: {} for query {}" with the
> first parameter being a primitive {{double}} and the second being an instance
> of {{QueryImpl}} [1]. On the other hand the TraceContext casts thats second
> parameter to {{String}} without a type check [2]. I would propose to use
> {{String.valueOf()}} here to get the proper {{toString()}} implementation of
> the {{QueryImpl}} object.
>
> [1]
> [https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-core/src/main/java/org/apache/jackrabbit/oak/query/QueryEngineImpl.java#L311]
> [2]
> [https://github.com/apache/sling-org-apache-sling-tracer/blob/master/src/main/java/org/apache/sling/tracer/internal/TracerContext.java#L92]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SLING-7583) Log tracer runs into ClassCastException for oak-queries
[
https://issues.apache.org/jira/browse/SLING-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-7583.
Resolution: Fixed
Fix Version/s: Log Tracer 1.0.8
> Log tracer runs into ClassCastException for oak-queries
> ---
>
> Key: SLING-7583
> URL: https://issues.apache.org/jira/browse/SLING-7583
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Log Tracer 1.0.6, Log Tracer 1.0.4
>Reporter: Dirk Rudolph
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: Log Tracer 1.0.8
>
>
> Oak's {{QueryEngineImpl}} logs the following "cost: {} for query {}" with the
> first parameter being a primitive {{double}} and the second being an instance
> of {{QueryImpl}} [1]. On the other hand the TraceContext casts thats second
> parameter to {{String}} without a type check [2]. I would propose to use
> {{String.valueOf()}} here to get the proper {{toString()}} implementation of
> the {{QueryImpl}} object.
>
> [1]
> [https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-core/src/main/java/org/apache/jackrabbit/oak/query/QueryEngineImpl.java#L311]
> [2]
> [https://github.com/apache/sling-org-apache-sling-tracer/blob/master/src/main/java/org/apache/sling/tracer/internal/TracerContext.java#L92]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-7583) Log tracer runs into ClassCastException for oak-queries
[
https://issues.apache.org/jira/browse/SLING-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra reassigned SLING-7583:
--
Assignee: Chetan Mehrotra
> Log tracer runs into ClassCastException for oak-queries
> ---
>
> Key: SLING-7583
> URL: https://issues.apache.org/jira/browse/SLING-7583
> Project: Sling
> Issue Type: Bug
> Components: Extensions
>Affects Versions: Log Tracer 1.0.6, Log Tracer 1.0.4
>Reporter: Dirk Rudolph
>Assignee: Chetan Mehrotra
>Priority: Minor
>
> Oak's {{QueryEngineImpl}} logs the following "cost: {} for query {}" with the
> first parameter being a primitive {{double}} and the second being an instance
> of {{QueryImpl}} [1]. On the other hand the TraceContext casts thats second
> parameter to {{String}} without a type check [2]. I would propose to use
> {{String.valueOf()}} here to get the proper {{toString()}} implementation of
> the {{QueryImpl}} object.
>
> [1]
> [https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.6.7/oak-core/src/main/java/org/apache/jackrabbit/oak/query/QueryEngineImpl.java#L311]
> [2]
> [https://github.com/apache/sling-org-apache-sling-tracer/blob/master/src/main/java/org/apache/sling/tracer/internal/TracerContext.java#L92]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SLING-7529) Log message layouts are not property inherited
[
https://issues.apache.org/jira/browse/SLING-7529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra closed SLING-7529.
--
> Log message layouts are not property inherited
> --
>
> Key: SLING-7529
> URL: https://issues.apache.org/jira/browse/SLING-7529
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Log 5.1.2
>Reporter: Fryderyk Wysocki
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: Commons Log 5.1.4
>
>
> Steps to reproduce on AEM 6.3 with Apache Sling Commons Log 5.1.2:
> 1. Create Logger Configuration for Logger "my.project", log file "error.log",
> log level 'Information" and message pattern "My project: \{5}"
> 2. Create an Slf4J logger for class my.project.Sample and use it to infolog
> message "test foo"
> 3. Change the configuration created in step 1 - update logger to
> "my.project.Sample"
> 4. Use the logger created in step 2 to infolog message "test bar"
> Expected result:
> 5. error.log file would contain messages "My project: test foo" and "My
> project: test bar"
> Actual result:
> 5. error.log file contains the message "test foo" in the format configured as
> the default format, but also contains the message "My project: test bar" -
> the second message, in the appropriate format.
> Investigation:
> Checking the source code, I've discovered the following in class
> 'LoggerSpecificEncoder', starting from line 47:
> {code:java}
> private Layout getLayout(String loggerName) {
> // TODO Handle layout inheritance wrt logger names
> Layout layout = layoutByCategory.get(loggerName);
> if (layout == null) {
> layout = defaultLayout;
> }
> return layout;
> }
> {code}
> Which means that, unless the configuration is created for the exact logger
> name, the default one will be used - the functionality is not broken, but
> simply not implemented.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SLING-7529) Log message layouts are not property inherited
[
https://issues.apache.org/jira/browse/SLING-7529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-7529.
Resolution: Fixed
Fix Version/s: Commons Log 5.1.4
Thanks [~CptBartender] for the PR. Its now merged to master
> Log message layouts are not property inherited
> --
>
> Key: SLING-7529
> URL: https://issues.apache.org/jira/browse/SLING-7529
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Log 5.1.2
>Reporter: Fryderyk Wysocki
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: Commons Log 5.1.4
>
>
> Steps to reproduce on AEM 6.3 with Apache Sling Commons Log 5.1.2:
> 1. Create Logger Configuration for Logger "my.project", log file "error.log",
> log level 'Information" and message pattern "My project: \{5}"
> 2. Create an Slf4J logger for class my.project.Sample and use it to infolog
> message "test foo"
> 3. Change the configuration created in step 1 - update logger to
> "my.project.Sample"
> 4. Use the logger created in step 2 to infolog message "test bar"
> Expected result:
> 5. error.log file would contain messages "My project: test foo" and "My
> project: test bar"
> Actual result:
> 5. error.log file contains the message "test foo" in the format configured as
> the default format, but also contains the message "My project: test bar" -
> the second message, in the appropriate format.
> Investigation:
> Checking the source code, I've discovered the following in class
> 'LoggerSpecificEncoder', starting from line 47:
> {code:java}
> private Layout getLayout(String loggerName) {
> // TODO Handle layout inheritance wrt logger names
> Layout layout = layoutByCategory.get(loggerName);
> if (layout == null) {
> layout = defaultLayout;
> }
> return layout;
> }
> {code}
> Which means that, unless the configuration is created for the exact logger
> name, the default one will be used - the functionality is not broken, but
> simply not implemented.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SLING-7529) Log message layouts are not property inherited
[
https://issues.apache.org/jira/browse/SLING-7529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra reassigned SLING-7529:
--
Assignee: Chetan Mehrotra
> Log message layouts are not property inherited
> --
>
> Key: SLING-7529
> URL: https://issues.apache.org/jira/browse/SLING-7529
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Log 5.1.2
>Reporter: Fryderyk Wysocki
>Assignee: Chetan Mehrotra
>Priority: Major
>
> Steps to reproduce on AEM 6.3 with Apache Sling Commons Log 5.1.2:
> 1. Create Logger Configuration for Logger "my.project", log file "error.log",
> log level 'Information" and message pattern "My project: \{5}"
> 2. Create an Slf4J logger for class my.project.Sample and use it to infolog
> message "test foo"
> 3. Change the configuration created in step 1 - update logger to
> "my.project.Sample"
> 4. Use the logger created in step 2 to infolog message "test bar"
> Expected result:
> 5. error.log file would contain messages "My project: test foo" and "My
> project: test bar"
> Actual result:
> 5. error.log file contains the message "test foo" in the format configured as
> the default format, but also contains the message "My project: test bar" -
> the second message, in the appropriate format.
> Investigation:
> Checking the source code, I've discovered the following in class
> 'LoggerSpecificEncoder', starting from line 47:
> {code:java}
> private Layout getLayout(String loggerName) {
> // TODO Handle layout inheritance wrt logger names
> Layout layout = layoutByCategory.get(loggerName);
> if (layout == null) {
> layout = defaultLayout;
> }
> return layout;
> }
> {code}
> Which means that, unless the configuration is created for the exact logger
> name, the default one will be used - the functionality is not broken, but
> simply not implemented.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SLING-2778) initial Sling/Jolokia integration bundle
[ https://issues.apache.org/jira/browse/SLING-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16336890#comment-16336890 ] Chetan Mehrotra commented on SLING-2778: [~justinedelson] Can you provide the path in sling repo (or in github) where this code lives? > initial Sling/Jolokia integration bundle > > > Key: SLING-2778 > URL: https://issues.apache.org/jira/browse/SLING-2778 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Justin Edelson >Assignee: Justin Edelson >Priority: Major > > As promised/threatened here: http://markmail.org/message/3r2wgtn4mz3z6b73 I'd > like to commit an initial implementation of a Sling/Jolokia > ((http://www.jolokia.org/)) integration. > Although Jolokia provides an OSGi bundle version, a Sling-specific > bundelization would provide authentication integration (similar to how the > Web Console provider works). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-7407) A thread pool with min size 1 uses only 1 thread for processing
Chetan Mehrotra created SLING-7407:
--
Summary: A thread pool with min size 1 uses only 1 thread for
processing
Key: SLING-7407
URL: https://issues.apache.org/jira/browse/SLING-7407
Project: Sling
Issue Type: Improvement
Components: Commons
Reporter: Chetan Mehrotra
Fix For: Commons Threads 3.2.12
If a thread pool is configured like below
{noformat}
org.apache.sling.commons.threads.impl.DefaultThreadPool.factory-oak
name="oak"
minPoolSize=I"1"
maxPoolSize=I"5"
{noformat}
Then only 1 thread would be used even if multiple jobs are assigned to the
pool. This happens because of strange behaviour of Java
[ThreadPoolExecutor|https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ThreadPoolExecutor.html]
bq. If there are more than corePoolSize but less than maximumPoolSize threads
running, a new thread will be created only *if the queue is full*
With unbounded queue used this lead to current behaviour. As a fix Sling Thread
Pool should adapt such a config
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-7407) A thread pool with min size 1 uses only 1 thread for processing
[
https://issues.apache.org/jira/browse/SLING-7407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated SLING-7407:
---
Issue Type: Bug (was: Improvement)
> A thread pool with min size 1 uses only 1 thread for processing
> ---
>
> Key: SLING-7407
> URL: https://issues.apache.org/jira/browse/SLING-7407
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Reporter: Chetan Mehrotra
>Priority: Major
> Fix For: Commons Threads 3.2.12
>
>
> If a thread pool is configured like below
> {noformat}
> org.apache.sling.commons.threads.impl.DefaultThreadPool.factory-oak
> name="oak"
> minPoolSize=I"1"
> maxPoolSize=I"5"
> {noformat}
> Then only 1 thread would be used even if multiple jobs are assigned to the
> pool. This happens because of strange behaviour of Java
> [ThreadPoolExecutor|https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ThreadPoolExecutor.html]
> bq. If there are more than corePoolSize but less than maximumPoolSize threads
> running, a new thread will be created only *if the queue is full*
> With unbounded queue used this lead to current behaviour. As a fix Sling
> Thread Pool should adapt such a config
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-6719) Add Server-Timing header to enable chrome log server timings
[ https://issues.apache.org/jira/browse/SLING-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-6719: --- Fix Version/s: (was: Log Tracer 1.0.2) Log Tracer 1.0.8 > Add Server-Timing header to enable chrome log server timings > > > Key: SLING-6719 > URL: https://issues.apache.org/jira/browse/SLING-6719 > Project: Sling > Issue Type: New Feature > Components: Extensions >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Major > Fix For: Log Tracer 1.0.8 > > > Chrome supports Server-Timing header [1] [2] to provide views around time > spent on server side for various sub calls as part of overall > request-response timing UI. > We should utlilize that in Sling to log time data for e.g. remote calls made > to Mongo as part of given request processing. > [1] https://w3c.github.io/server-timing/ > [2] https://ma.ttias.be/server-timings-chrome-devtools/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-6506) Sling Log Tracer queries reports Plan that does not match Query statement
[
https://issues.apache.org/jira/browse/SLING-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-6506.
Resolution: Fixed
Fix Version/s: (was: Log Tracer 1.0.2)
Log Tracer 1.0.8
Thanks [~empire29] for the improvement. Some how missed this in last release. I
have reworked the patch a bit.
Merged the changes with [commit
1|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-tracer.git;a=commitdiff;h=c09c86b085608915206a49ca0177899f6485ce88]
and [commit
2|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-tracer.git;a=commitdiff;h=c3443eaeb8ec12156947588e9cf05b018c1b5464]
> Sling Log Tracer queries reports Plan that does not match Query statement
> -
>
> Key: SLING-6506
> URL: https://issues.apache.org/jira/browse/SLING-6506
> Project: Sling
> Issue Type: Bug
>Affects Versions: Log Tracer 0.0.2
>Reporter: David Gonzalez
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: Log Tracer 1.0.8
>
> Attachments: tracer-error-output.txt, tracer-error-screencap.png
>
>
> The Queries data set from Sling Log Tracer (1.0.2) may report the wrong Query
> plan for the query.
> {noformat}
> "query": "//*[jcr:contains(.,
> '\"/content/dam/we-retail/en/people/mens/men_1.jpg\"')]",
> "plan": "[nt:unstructured] as [a] /*
> lucene:ntBaseLucene(/oak:index/ntBaseLucene)
> dam:resolvedPath:/content/dam/we-retail/en/people/mens/men_1.jpg where
> [a].[dam:resolvedPath] = '/content/dam/we-retail/en/people/mens/men_1.jpg' */"
> {noformat}
> Attached raw tracer output from Felix console.
> Explaining the query statement via Oak gives a different (and correct) plan.
> /cc [~chetanm]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SLING-7348) Switch to OSGi annotation for Tracer bundle
[ https://issues.apache.org/jira/browse/SLING-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra closed SLING-7348. -- > Switch to OSGi annotation for Tracer bundle > --- > > Key: SLING-7348 > URL: https://issues.apache.org/jira/browse/SLING-7348 > Project: Sling > Issue Type: Task > Components: Extensions >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: Log Tracer 1.0.6 > > > Switch to official osgi annotations -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-7348) Switch to OSGi annotation for Tracer bundle
[ https://issues.apache.org/jira/browse/SLING-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-7348. Resolution: Fixed Done with [15ba5447285f5f|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-tracer.git;a=commitdiff;h=15ba5447285f5f97690c4fd1e96a42a469915c6b] > Switch to OSGi annotation for Tracer bundle > --- > > Key: SLING-7348 > URL: https://issues.apache.org/jira/browse/SLING-7348 > Project: Sling > Issue Type: Task > Components: Extensions >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: Log Tracer 1.0.6 > > > Switch to official osgi annotations -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-5669) Restrict usage of log tracing feature with access control
[ https://issues.apache.org/jira/browse/SLING-5669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-5669: --- Fix Version/s: (was: Log Tracer 1.0.6) Log Tracer 1.0.8 > Restrict usage of log tracing feature with access control > - > > Key: SLING-5669 > URL: https://issues.apache.org/jira/browse/SLING-5669 > Project: Sling > Issue Type: Improvement > Components: Extensions >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: Log Tracer 1.0.8 > > > In SLING-5459 [~bdelacretaz] suggested that Tracer should provide a way to > secure use of the tracing feature to specific user. > This can be done by having a specific path in content and check that current > user has read permission on that path. This would ensure that feature can be > more safely enabled. Note that even without this trace logs are only > accessible to admin user only. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SLING-7348) Switch to OSGi annotation for Tracer bundle
Chetan Mehrotra created SLING-7348: -- Summary: Switch to OSGi annotation for Tracer bundle Key: SLING-7348 URL: https://issues.apache.org/jira/browse/SLING-7348 Project: Sling Issue Type: Task Components: Extensions Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Fix For: Log Tracer 1.0.6 Switch to official osgi annotations -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (SLING-7047) Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.
[ https://issues.apache.org/jira/browse/SLING-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra closed SLING-7047. -- > Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency. > -- > > Key: SLING-7047 > URL: https://issues.apache.org/jira/browse/SLING-7047 > Project: Sling > Issue Type: Task >Reporter: Ian Boston >Assignee: Chetan Mehrotra > Fix For: commons metrics 1.2.4, Starter 10 > > > as per https://github.com/ieb/slingmetrics/issues/1 > Not certain where the Dropwizard Metrics bundle is included, but it would be > good to make it work for any JDK, not just the Sun/Oracle JDK. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (SLING-6702) Make MetricsService accessible as easily as a Logger
[
https://issues.apache.org/jira/browse/SLING-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra closed SLING-6702.
--
> Make MetricsService accessible as easily as a Logger
>
>
> Key: SLING-6702
> URL: https://issues.apache.org/jira/browse/SLING-6702
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: Commons Metrics 1.2.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: commons metrics 1.2.4
>
>
> Metrics are useful in all classes, not only OSGi components, so getting the
> {{MetricsService}} should be as useful as getting a {{Logger}} for example.
> I'll add a public {{MetricsServiceFactory}} class to our metrics module,
> usable like
> {code}
> MetricsService ms =
> MetricsServiceFactory.getMetricsService(this.getClass());
> {code}
> There's already a private {{MetricsServiceFactory}} class in that module,
> I'll rename that to {{InternalMetricsServiceFactory}} to avoid confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (SLING-7062) Commons metrics inventory closes zip
[
https://issues.apache.org/jira/browse/SLING-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra closed SLING-7062.
--
> Commons metrics inventory closes zip
>
>
> Key: SLING-7062
> URL: https://issues.apache.org/jira/browse/SLING-7062
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Metrics 1.0.0
>Reporter: Marcel Reutegger
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: commons metrics 1.2.4
>
> Attachments: SLING-7062.patch
>
>
> The inventory printer implementation of {{MetricWebConsolePlugin}} closes the
> passed {{PrintWriter}} though {{ConsoleReporter.close()}}. This aborts the
> configuration status zip generation process and subsequent inventory printer
> output is missing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (SLING-7028) Commons Metrics Web Console outputs all Histograms as durations
[ https://issues.apache.org/jira/browse/SLING-7028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra closed SLING-7028. -- > Commons Metrics Web Console outputs all Histograms as durations > --- > > Key: SLING-7028 > URL: https://issues.apache.org/jira/browse/SLING-7028 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Metrics 1.2.2 >Reporter: Justin Edelson >Assignee: Justin Edelson > Fix For: commons metrics 1.2.4 > > Attachments: SLING-7028.diff > > > For the purpose of the Web Console plugin, Histograms from the > MetricsRegistry are assumed to be durations and are output as if the values > are in milliseconds. This is not a safe assumption and in fact would > generally not be the case since durations would be better tracked through the > Timer type (which uses a Histogram internally) not by direct use of the > Histogram type. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (SLING-7031) Write (subset) of metrics to log file on a recurring basis
[ https://issues.apache.org/jira/browse/SLING-7031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra closed SLING-7031. -- > Write (subset) of metrics to log file on a recurring basis > -- > > Key: SLING-7031 > URL: https://issues.apache.org/jira/browse/SLING-7031 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Justin Edelson >Assignee: Justin Edelson > Fix For: commons metrics 1.2.4 > > Attachments: SLING-7031.diff > > > For ease of visibility and extraction, we should provide a way to output a > set of metrics to the log file on a recurring basis. Most of this > functionality is already provided by the Metrics library, we can just wrap it > in a nice OSGi config-based component. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-6474) Commons Metrics DOES not declare provide capability for Metrics service
[ https://issues.apache.org/jira/browse/SLING-6474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276337#comment-16276337 ] Chetan Mehrotra commented on SLING-6474: [~nmwael] I have moved this issue to next release as was not able to figure out easy way to add the capapbility in additive manner i.e. have bnd compute defaults and then have the MetricRegistry added to the default. Would try to figure it out using some macro to see if its possible In the meantime if you can provide any patch to achieve the same then we can use that also and cut a new release > Commons Metrics DOES not declare provide capability for Metrics service > --- > > Key: SLING-6474 > URL: https://issues.apache.org/jira/browse/SLING-6474 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Metrics 1.2.0 >Reporter: Nino Martinez >Assignee: Chetan Mehrotra > Fix For: Commons Metrics 1.2.6 > > > Commons Metrics needs to declare provide capability for > org.apache.sling.commons.metrics.MetricsService in manifest.MF > otherwise other bundles that specifies require capability on the > MetricsService will fail to start. > AS of maven bundle plugin 3.2.0 this will become a problem, since they fixed > the capabilities generation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-6474) Commons Metrics DOES not declare provide capability for Metrics service
[ https://issues.apache.org/jira/browse/SLING-6474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-6474: --- Fix Version/s: (was: commons metrics 1.2.4) Commons Metrics 1.2.6 > Commons Metrics DOES not declare provide capability for Metrics service > --- > > Key: SLING-6474 > URL: https://issues.apache.org/jira/browse/SLING-6474 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: Commons Metrics 1.2.0 >Reporter: Nino Martinez >Assignee: Chetan Mehrotra > Fix For: Commons Metrics 1.2.6 > > > Commons Metrics needs to declare provide capability for > org.apache.sling.commons.metrics.MetricsService in manifest.MF > otherwise other bundles that specifies require capability on the > MetricsService will fail to start. > AS of maven bundle plugin 3.2.0 this will become a problem, since they fixed > the capabilities generation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-6702) Make MetricsService accessible as easily as a Logger
[
https://issues.apache.org/jira/browse/SLING-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-6702.
Resolution: Fixed
> Make MetricsService accessible as easily as a Logger
>
>
> Key: SLING-6702
> URL: https://issues.apache.org/jira/browse/SLING-6702
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: Commons Metrics 1.2.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: commons metrics 1.2.4
>
>
> Metrics are useful in all classes, not only OSGi components, so getting the
> {{MetricsService}} should be as useful as getting a {{Logger}} for example.
> I'll add a public {{MetricsServiceFactory}} class to our metrics module,
> usable like
> {code}
> MetricsService ms =
> MetricsServiceFactory.getMetricsService(this.getClass());
> {code}
> There's already a private {{MetricsServiceFactory}} class in that module,
> I'll rename that to {{InternalMetricsServiceFactory}} to avoid confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-6702) Make MetricsService accessible as easily as a Logger
[
https://issues.apache.org/jira/browse/SLING-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16274245#comment-16274245
]
Chetan Mehrotra commented on SLING-6702:
Had an offline discussion with [~bdelacretaz] - We decided to add a note in
MetricServiceImpl to ensure that later if any support for OSGi config is added
then rewiring of metric service should be looked into
Done that with e041e99219f544
> Make MetricsService accessible as easily as a Logger
>
>
> Key: SLING-6702
> URL: https://issues.apache.org/jira/browse/SLING-6702
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: Commons Metrics 1.2.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: commons metrics 1.2.4
>
>
> Metrics are useful in all classes, not only OSGi components, so getting the
> {{MetricsService}} should be as useful as getting a {{Logger}} for example.
> I'll add a public {{MetricsServiceFactory}} class to our metrics module,
> usable like
> {code}
> MetricsService ms =
> MetricsServiceFactory.getMetricsService(this.getClass());
> {code}
> There's already a private {{MetricsServiceFactory}} class in that module,
> I'll rename that to {{InternalMetricsServiceFactory}} to avoid confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SLING-7045) OSGi services should be managed by DS
[ https://issues.apache.org/jira/browse/SLING-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-7045. Resolution: Won't Fix Fix Version/s: (was: commons metrics 1.2.4) > OSGi services should be managed by DS > - > > Key: SLING-7045 > URL: https://issues.apache.org/jira/browse/SLING-7045 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler > > MetricsServiceImpl is currently registering two services in its activate > method - there seems to be no real reason doing this manually and the > services should rather be registered by DS -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-7282) Enable packaging data support in stacktraces by default
[ https://issues.apache.org/jira/browse/SLING-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-7282. Resolution: Fixed Done with [commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-starter.git;a=commitdiff;h=bf41073f4176eefc59a5c8e71e179ea754846b02] > Enable packaging data support in stacktraces by default > --- > > Key: SLING-7282 > URL: https://issues.apache.org/jira/browse/SLING-7282 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: Launchpad Builder 10 > > > Enable the support for including packaging data with stacktrace in logs by > default (SLING-3049) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SLING-7282) Enable packaging data support in stacktraces by default
Chetan Mehrotra created SLING-7282: -- Summary: Enable packaging data support in stacktraces by default Key: SLING-7282 URL: https://issues.apache.org/jira/browse/SLING-7282 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Fix For: Launchpad Builder 10 Enable the support for including packaging data with stacktrace in logs by default (SLING-3049) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (SLING-7239) LogbackManager may miss out some OSGi config at time of startup
[
https://issues.apache.org/jira/browse/SLING-7239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra closed SLING-7239.
--
> LogbackManager may miss out some OSGi config at time of startup
> ---
>
> Key: SLING-7239
> URL: https://issues.apache.org/jira/browse/SLING-7239
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 5.1.0
>
>
> {{LogbackManager}} currently upon construction reads all the OSGi config and
> configure them in Logback. Config which comes laters leads to logback reset.
> However during the time when its getting constructed it has a logic to ignore
> the reset flag initialization for startup. This may lead to a race condition
> where some OSGi configs are picked up while it is getting constructed and
> some OSGi config arriving later are not picked up. For e.g.
> # LogbackManager constructor is invoked
> # It constructs LogConfigManager which registers the managed services
> # ManagedServices receive some OSGi config and push them to LogConfigManager
> # LogbackManager picks them up and add them to Logback but still startup is
> not finished i.e. started = true is not called
> # Some more OSGi config arrive - These would get ignored as
> LogbackManager#configChanged would ignore the calls because started != true
> # LogbackManager startup completes and started = true
> So here configs at #5 would not be picked up unless at #7 some more OSGi
> config arrive. Or some one modifies the config post system start
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (SLING-3049) Make Logback Stacktrace Packaging data support OSGi aware
[ https://issues.apache.org/jira/browse/SLING-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra closed SLING-3049. -- > Make Logback Stacktrace Packaging data support OSGi aware > - > > Key: SLING-3049 > URL: https://issues.apache.org/jira/browse/SLING-3049 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Labels: logback > Fix For: Commons Log 5.1.0 > > Attachments: SLING-3049.patch, > buildbot-exceptions-while-stopping-jetty.txt > > > Logback provides a useful feature where it dumps the Class packaging Data > along with the stacktrace [1]. This provides a quick view of the location > from where classes in a given stacktrace are coming. Its default logic does > not work properly in OSGi env. Hence it would be useful to patch its logic to > become OSGi aware > [1] http://logback.qos.ch/reasonsToSwitch.html#packagingData -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (SLING-6044) Conflicting LogManager and LogWriter if using the same logfile
[
https://issues.apache.org/jira/browse/SLING-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra closed SLING-6044.
--
> Conflicting LogManager and LogWriter if using the same logfile
> --
>
> Key: SLING-6044
> URL: https://issues.apache.org/jira/browse/SLING-6044
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Affects Versions: Commons Log 4.0.2
>Reporter: Jörg Hoh
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 5.1.0
>
> Attachments: SLING-6044-multiple-loggers-writers.jpg
>
>
> When you have a logmanager and a logwriter pointing to the same file, you get
> an exception like this:
> {panel}
> 07.09.2016 17:33:31.126 *ERROR* [] CM Configuration Updater (Update:
> pid=org.apache.sling.commons.log.LogManager) org.apache.felix.configadmin
> Service [org.apache.felix.cm.ConfigurationAdmin,9,
> [org.osgi.service.cm.ConfigurationAdmin]]
> [org.osgi.service.cm.ManagedService, id=10,
> bundle=7/slinginstall:c:\java\IBM\LibertyProfile\usr\servers\aem-1\sling\_\launchpad\startup\1\org.apache.sling.commons.log-4.0.0.jar]:
> Updating property org.apache.sling.commons.log.file of configuration
> org.apache.sling.commons.log.LogManager caused a problem: LogFile
> C:\java\IBM\LibertyProfile\usr\servers\aem-1\aemlogs\logs\error.log already
> configured by configuration
> org.apache.sling.commons.log.LogManager.factory.writer.8402a603-bdef-4404-9ff1-0e0f592578af
> (org.osgi.service.cm.ConfigurationException:
> org.apache.sling.commons.log.file : LogFile
> C:\java\IBM\LibertyProfile\usr\servers\aem-1\aemlogs\logs\error.log already
> configured by configuration
> org.apache.sling.commons.log.LogManager.factory.writer.8402a603-bdef-4404-9ff1-0e0f592578af)
>
> org.osgi.service.cm.ConfigurationException: org.apache.sling.commons.log.file
> : LogFile C:\java\IBM\LibertyProfile\usr\servers\aem-1\aemlogs\logs\error.log
> already configured by configuration
> org.apache.sling.commons.log.LogManager.factory.writer.8402a603-bdef-4404-9ff1-0e0f592578af
>
> at
> org.apache.sling.commons.log.logback.internal.config.GlobalConfigurator.updated(GlobalConfigurator.java:32)
> at
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:148)
>
> at
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:81)
>
> at
> org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1744)
>
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> at java.lang.Thread.run(Thread.java:744)
> Caused by:
> org.apache.sling.commons.log.logback.internal.config.ConfigurationException:
> at
> org.apache.sling.commons.log.logback.internal.LogConfigManager.updateLogWriter(LogConfigManager.java:398)
>
> at
> org.apache.sling.commons.log.logback.internal.LogConfigManager.updateGlobalConfiguration(LogConfigManager.java:327)
>
> at
> org.apache.sling.commons.log.logback.internal.config.GlobalConfigurator.updated(GlobalConfigurator.java:30)
>
> ... 5 common frames omitted
> {panel}
> Obviously the Logmanager internally provides a Logwriter, so these conflict.
> This should be documented.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (SLING-7224) Switch to standard OSGi annotations
[ https://issues.apache.org/jira/browse/SLING-7224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra closed SLING-7224. -- > Switch to standard OSGi annotations > --- > > Key: SLING-7224 > URL: https://issues.apache.org/jira/browse/SLING-7224 > Project: Sling > Issue Type: Task > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: Commons Log 5.1.0 > > > Switch to official OSGi annotations -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (SLING-7221) Update osgi core dependency to 6.0
[ https://issues.apache.org/jira/browse/SLING-7221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra closed SLING-7221. -- > Update osgi core dependency to 6.0 > -- > > Key: SLING-7221 > URL: https://issues.apache.org/jira/browse/SLING-7221 > Project: Sling > Issue Type: Task > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: Commons Log 5.1.0 > > > Update various dependencies in Commons Log. Particularly dependency on > osgi.core to 6.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (SLING-6482) Commons Log WebConsole: Exception when creating logger with an empty log file
[
https://issues.apache.org/jira/browse/SLING-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra closed SLING-6482.
--
> Commons Log WebConsole: Exception when creating logger with an empty log file
> -
>
> Key: SLING-6482
> URL: https://issues.apache.org/jira/browse/SLING-6482
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Log 5.0.0
>Reporter: Bjoern Weide
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: Commons Log 5.1.0
>
> Attachments: SLING-6482-v01.patch
>
>
> When creating a new logger via WebConsole specifying an empty logfile it
> causes an StringIndexOutOfBoundsException when (re-)opening the WebConsole.
> {noformat}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1931)
> at
> org.apache.sling.commons.log.logback.internal.SlingLogPanel.getPath(SlingLogPanel.java:791)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (SLING-6577) StringIndexOutOfBoundsException in Sling Log Web Console when creating new logger with absolute file name
[
https://issues.apache.org/jira/browse/SLING-6577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra closed SLING-6577.
--
> StringIndexOutOfBoundsException in Sling Log Web Console when creating new
> logger with absolute file name
> -
>
> Key: SLING-6577
> URL: https://issues.apache.org/jira/browse/SLING-6577
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Log 5.0.0
>Reporter: Konrad Windszus
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 5.1.0
>
>
> After adding a new logger via the web console exposed at
> {{/system/console/slinglog}} with an absolute filename (one starting with
> "/"), the following exception is thrown
> {code}
> 28.02.2017 16:47:31.300 *ERROR* [qtp455076072-280]
> org.apache.felix.http.jetty Exception while processing request to
> /system/console/slinglog (java.lang.StringIndexOutOfBoundsException: String
> index out of range: -42)
> java.lang.StringIndexOutOfBoundsException: String index out of range: -42
> at java.lang.String.substring(String.java:1931)
> at
> org.apache.sling.commons.log.logback.internal.SlingLogPanel.getPath(SlingLogPanel.java:791)
> at
> org.apache.sling.commons.log.logback.internal.SlingLogPanel.appendOsgiConfiguredLoggerData(SlingLogPanel.java:221)
> at
> org.apache.sling.commons.log.logback.internal.SlingLogPanel.render(SlingLogPanel.java:110)
> at
> org.apache.sling.commons.log.webconsole.internal.LogWebConsolePlugin.renderContent(LogWebConsolePlugin.java:79)
> at
> org.apache.felix.webconsole.AbstractWebConsolePlugin.doGet(AbstractWebConsolePlugin.java:194)
> {code}
> This is related to the exception being mentioned in SLING-6482.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (SLING-7220) Update Logback to 1.2.3 version
[ https://issues.apache.org/jira/browse/SLING-7220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra closed SLING-7220. -- > Update Logback to 1.2.3 version > --- > > Key: SLING-7220 > URL: https://issues.apache.org/jira/browse/SLING-7220 > Project: Sling > Issue Type: Task > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: Commons Log 5.1.0 > > > Update Logback to 1.2.3 version > See https://logback.qos.ch/news.html for release notes. Specially 1.2.0 > release has significant performance improvements -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (SLING-7222) Too frequent samples
[
https://issues.apache.org/jira/browse/SLING-7222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra closed SLING-7222.
--
> Too frequent samples
>
>
> Key: SLING-7222
> URL: https://issues.apache.org/jira/browse/SLING-7222
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Metrics RRD4J 1.0.0
>Reporter: Marcel Reutegger
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.2
>
> Attachments: SLING-7222.patch
>
>
> The metrics reporter sometimes logs error messages telling samples are
> reported too frequently (more than once a second):
> {noformat}
> 29.10.2017 19:01:25.384 *ERROR* [metrics-RRD4JReporter-1-thread-1]
> com.codahale.metrics.ScheduledReporter RuntimeException thrown from
> RRD4JReporter#report. Exception was suppressed.
> java.lang.IllegalArgumentException: Bad sample time: 1509300085. Last update
> time was 1509300085, at least one second step is required
> at org.rrd4j.core.RrdDb.store(RrdDb.java:517)
> at org.rrd4j.core.Sample.update(Sample.java:194)
> at
> org.apache.sling.commons.metrics.rrd4j.impl.RRD4JReporter.report(RRD4JReporter.java:239)
> at
> com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:162)
> at
> com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:117)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 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
(v6.4.14#64029)
[jira] [Closed] (SLING-7223) Spikes in RRD after restart
[ https://issues.apache.org/jira/browse/SLING-7223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra closed SLING-7223. -- > Spikes in RRD after restart > --- > > Key: SLING-7223 > URL: https://issues.apache.org/jira/browse/SLING-7223 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Metrics RRD4J 1.0.0 >Reporter: Marcel Reutegger >Assignee: Chetan Mehrotra > Fix For: Commons Metrics RRD4J 1.0.2 > > Attachments: SLING-7223.patch > > > Running the reporter for some time and then restarting the process shows > spikes in the collected data. These are caused by counter gauges that are > reset to zero after a restart. RRD interprets them as 32bit or 64bit integer > overflows and calculates incorrect values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-6702) Make MetricsService accessible as easily as a Logger
[
https://issues.apache.org/jira/browse/SLING-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16274004#comment-16274004
]
Chetan Mehrotra commented on SLING-6702:
[~bdelacretaz] Should we resolve this issue?
> Make MetricsService accessible as easily as a Logger
>
>
> Key: SLING-6702
> URL: https://issues.apache.org/jira/browse/SLING-6702
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: Commons Metrics 1.2.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: commons metrics 1.2.4
>
>
> Metrics are useful in all classes, not only OSGi components, so getting the
> {{MetricsService}} should be as useful as getting a {{Logger}} for example.
> I'll add a public {{MetricsServiceFactory}} class to our metrics module,
> usable like
> {code}
> MetricsService ms =
> MetricsServiceFactory.getMetricsService(this.getClass());
> {code}
> There's already a private {{MetricsServiceFactory}} class in that module,
> I'll rename that to {{InternalMetricsServiceFactory}} to avoid confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SLING-7270) Update paxexam dependency to 3.5.0
[ https://issues.apache.org/jira/browse/SLING-7270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-7270: --- Summary: Update paxexam dependency to 3.5.0 (was: Update paxexam dependency to 3.50) > Update paxexam dependency to 3.5.0 > -- > > Key: SLING-7270 > URL: https://issues.apache.org/jira/browse/SLING-7270 > Project: Sling > Issue Type: Task > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: DataSource Provider 1.0.4 > > > Update the dependencies for pax exam > * Pax Exam 3.5.0 > * Felix Framework 5.6.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SLING-7270) Update paxexam dependency to 3.50
Chetan Mehrotra created SLING-7270: -- Summary: Update paxexam dependency to 3.50 Key: SLING-7270 URL: https://issues.apache.org/jira/browse/SLING-7270 Project: Sling Issue Type: Task Components: Commons Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Fix For: DataSource Provider 1.0.4 Update the dependencies for pax exam * Pax Exam 3.5.0 * Felix Framework 5.6.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (SLING-7045) OSGi services should be managed by DS
[ https://issues.apache.org/jira/browse/SLING-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266470#comment-16266470 ] Chetan Mehrotra edited comment on SLING-7045 at 11/27/17 7:48 AM: -- bq. I dont understand why simply DS can be used for the other case? Sounds way simpler to me So far I do not know how to use DS as factory for some other type. So instead of having the component itself register as a service (via implementing service interface) I need it to register a different type. For that I am using activate method to register the MetricsService instance [~cziegeler] Can you provide a rough example of the type of change you are thinking about was (Author: chetanm): bq. I dont understand why simply DS can be used for the other case? Sounds way simpler to me So far I do not know how to use DS as factory for some other type. So instead of having the component itself register as a service (via implementing service interface) I need it to register a different type. For that I am using activate method to register the MetricsService instance > OSGi services should be managed by DS > - > > Key: SLING-7045 > URL: https://issues.apache.org/jira/browse/SLING-7045 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler > Fix For: commons metrics 1.2.4 > > > MetricsServiceImpl is currently registering two services in its activate > method - there seems to be no real reason doing this manually and the > services should rather be registered by DS -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7045) OSGi services should be managed by DS
[ https://issues.apache.org/jira/browse/SLING-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266470#comment-16266470 ] Chetan Mehrotra commented on SLING-7045: bq. I dont understand why simply DS can be used for the other case? Sounds way simpler to me So far I do not know how to use DS as factory for some other type. So instead of having the component itself register as a service (via implementing service interface) I need it to register a different type. For that I am using activate method to register the MetricsService instance > OSGi services should be managed by DS > - > > Key: SLING-7045 > URL: https://issues.apache.org/jira/browse/SLING-7045 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler > Fix For: commons metrics 1.2.4 > > > MetricsServiceImpl is currently registering two services in its activate > method - there seems to be no real reason doing this manually and the > services should rather be registered by DS -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-7043: --- Fix Version/s: (was: commons metrics 1.2.4) Commons Metrics 1.2.6 > Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction > -- > > Key: SLING-7043 > URL: https://issues.apache.org/jira/browse/SLING-7043 > Project: Sling > Issue Type: Bug >Affects Versions: Commons Metrics 1.0.0 >Reporter: Carsten Ziegeler >Priority: Blocker > Fix For: Commons Metrics 1.2.6 > > > commons metrics provides a nice abstraction over com.codahale.metrics - > however it is exporting com.codahale.metrics.MetricRegistry which seems to > be the only way to get at registered metrics objects. Which in turn is > completely breaking the purpose of this bundle. > So we should > a) drop exporting that service and avoid leaking internal implementation > details > b) create our own version of the registry service -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-6044) Conflicting LogManager and LogWriter if using the same logfile
[
https://issues.apache.org/jira/browse/SLING-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-6044.
Resolution: Fixed
Updated the site with
[commit|https://gitbox.apache.org/repos/asf?p=sling-site.git;a=commitdiff;h=58910b8e2e96de67ffe2909f6dadb31ad5da6db7]
> Conflicting LogManager and LogWriter if using the same logfile
> --
>
> Key: SLING-6044
> URL: https://issues.apache.org/jira/browse/SLING-6044
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Affects Versions: Commons Log 4.0.2
>Reporter: Jörg Hoh
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 5.1.0
>
> Attachments: SLING-6044-multiple-loggers-writers.jpg
>
>
> When you have a logmanager and a logwriter pointing to the same file, you get
> an exception like this:
> {panel}
> 07.09.2016 17:33:31.126 *ERROR* [] CM Configuration Updater (Update:
> pid=org.apache.sling.commons.log.LogManager) org.apache.felix.configadmin
> Service [org.apache.felix.cm.ConfigurationAdmin,9,
> [org.osgi.service.cm.ConfigurationAdmin]]
> [org.osgi.service.cm.ManagedService, id=10,
> bundle=7/slinginstall:c:\java\IBM\LibertyProfile\usr\servers\aem-1\sling\_\launchpad\startup\1\org.apache.sling.commons.log-4.0.0.jar]:
> Updating property org.apache.sling.commons.log.file of configuration
> org.apache.sling.commons.log.LogManager caused a problem: LogFile
> C:\java\IBM\LibertyProfile\usr\servers\aem-1\aemlogs\logs\error.log already
> configured by configuration
> org.apache.sling.commons.log.LogManager.factory.writer.8402a603-bdef-4404-9ff1-0e0f592578af
> (org.osgi.service.cm.ConfigurationException:
> org.apache.sling.commons.log.file : LogFile
> C:\java\IBM\LibertyProfile\usr\servers\aem-1\aemlogs\logs\error.log already
> configured by configuration
> org.apache.sling.commons.log.LogManager.factory.writer.8402a603-bdef-4404-9ff1-0e0f592578af)
>
> org.osgi.service.cm.ConfigurationException: org.apache.sling.commons.log.file
> : LogFile C:\java\IBM\LibertyProfile\usr\servers\aem-1\aemlogs\logs\error.log
> already configured by configuration
> org.apache.sling.commons.log.LogManager.factory.writer.8402a603-bdef-4404-9ff1-0e0f592578af
>
> at
> org.apache.sling.commons.log.logback.internal.config.GlobalConfigurator.updated(GlobalConfigurator.java:32)
> at
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:148)
>
> at
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:81)
>
> at
> org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1744)
>
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> at java.lang.Thread.run(Thread.java:744)
> Caused by:
> org.apache.sling.commons.log.logback.internal.config.ConfigurationException:
> at
> org.apache.sling.commons.log.logback.internal.LogConfigManager.updateLogWriter(LogConfigManager.java:398)
>
> at
> org.apache.sling.commons.log.logback.internal.LogConfigManager.updateGlobalConfiguration(LogConfigManager.java:327)
>
> at
> org.apache.sling.commons.log.logback.internal.config.GlobalConfigurator.updated(GlobalConfigurator.java:30)
>
> ... 5 common frames omitted
> {panel}
> Obviously the Logmanager internally provides a Logwriter, so these conflict.
> This should be documented.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7239) LogbackManager may miss out some OSGi config at time of startup
[
https://issues.apache.org/jira/browse/SLING-7239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266423#comment-16266423
]
Chetan Mehrotra commented on SLING-7239:
Fixed this with
[commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-commons-log.git;a=commitdiff;h=3271098b98cc661a3ee3cdb72aa1ef653b5d873d]
The test creates around 200+ OSGi config for loggers which then fails on my
setup as number of log files created are lesser. Post fix the test passes. The
test does not fail for lower config count like 100 on my machine. So failure
depends on machine as it is due to race condition
> LogbackManager may miss out some OSGi config at time of startup
> ---
>
> Key: SLING-7239
> URL: https://issues.apache.org/jira/browse/SLING-7239
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 5.0.4
>
>
> {{LogbackManager}} currently upon construction reads all the OSGi config and
> configure them in Logback. Config which comes laters leads to logback reset.
> However during the time when its getting constructed it has a logic to ignore
> the reset flag initialization for startup. This may lead to a race condition
> where some OSGi configs are picked up while it is getting constructed and
> some OSGi config arriving later are not picked up. For e.g.
> # LogbackManager constructor is invoked
> # It constructs LogConfigManager which registers the managed services
> # ManagedServices receive some OSGi config and push them to LogConfigManager
> # LogbackManager picks them up and add them to Logback but still startup is
> not finished i.e. started = true is not called
> # Some more OSGi config arrive - These would get ignored as
> LogbackManager#configChanged would ignore the calls because started != true
> # LogbackManager startup completes and started = true
> So here configs at #5 would not be picked up unless at #7 some more OSGi
> config arrive. Or some one modifies the config post system start
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SLING-7239) LogbackManager may miss out some OSGi config at time of startup
[
https://issues.apache.org/jira/browse/SLING-7239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-7239.
Resolution: Fixed
> LogbackManager may miss out some OSGi config at time of startup
> ---
>
> Key: SLING-7239
> URL: https://issues.apache.org/jira/browse/SLING-7239
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 5.0.4
>
>
> {{LogbackManager}} currently upon construction reads all the OSGi config and
> configure them in Logback. Config which comes laters leads to logback reset.
> However during the time when its getting constructed it has a logic to ignore
> the reset flag initialization for startup. This may lead to a race condition
> where some OSGi configs are picked up while it is getting constructed and
> some OSGi config arriving later are not picked up. For e.g.
> # LogbackManager constructor is invoked
> # It constructs LogConfigManager which registers the managed services
> # ManagedServices receive some OSGi config and push them to LogConfigManager
> # LogbackManager picks them up and add them to Logback but still startup is
> not finished i.e. started = true is not called
> # Some more OSGi config arrive - These would get ignored as
> LogbackManager#configChanged would ignore the calls because started != true
> # LogbackManager startup completes and started = true
> So here configs at #5 would not be picked up unless at #7 some more OSGi
> config arrive. Or some one modifies the config post system start
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SLING-6482) Commons Log WebConsole: Exception when creating logger with an empty log file
[
https://issues.apache.org/jira/browse/SLING-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-6482.
Resolution: Fixed
> Commons Log WebConsole: Exception when creating logger with an empty log file
> -
>
> Key: SLING-6482
> URL: https://issues.apache.org/jira/browse/SLING-6482
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Log 5.0.0
>Reporter: Bjoern Weide
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: Commons Log 5.0.4
>
> Attachments: SLING-6482-v01.patch
>
>
> When creating a new logger via WebConsole specifying an empty logfile it
> causes an StringIndexOutOfBoundsException when (re-)opening the WebConsole.
> {noformat}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1931)
> at
> org.apache.sling.commons.log.logback.internal.SlingLogPanel.getPath(SlingLogPanel.java:791)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SLING-7269) Update DataSource provider to use Tomcat 8.5.23
[ https://issues.apache.org/jira/browse/SLING-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-7269: --- Fix Version/s: DataSource Provider 1.0.4 > Update DataSource provider to use Tomcat 8.5.23 > --- > > Key: SLING-7269 > URL: https://issues.apache.org/jira/browse/SLING-7269 > Project: Sling > Issue Type: Task > Components: Extensions >Affects Versions: DataSource Provider 1.0.2 >Reporter: Julian Reschke >Assignee: Chetan Mehrotra > Fix For: DataSource Provider 1.0.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (SLING-7269) Update DataSource provider to use Tomcat 8.5.23
[ https://issues.apache.org/jira/browse/SLING-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra reassigned SLING-7269: -- Assignee: Chetan Mehrotra > Update DataSource provider to use Tomcat 8.5.23 > --- > > Key: SLING-7269 > URL: https://issues.apache.org/jira/browse/SLING-7269 > Project: Sling > Issue Type: Task > Components: Extensions >Affects Versions: DataSource Provider 1.0.2 >Reporter: Julian Reschke >Assignee: Chetan Mehrotra > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-6474) Commons Metrics DOES not declare provide capability for Metrics service
[
https://issues.apache.org/jira/browse/SLING-6474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265194#comment-16265194
]
Chetan Mehrotra commented on SLING-6474:
Currently it generates following provide capability
{noformat}
Provide-Capability
osgi.service;objectClass:List="javax.servlet.Servlet,org.apache.felix.inventory.InventoryPrinter"
{noformat}
Not sure how to add one for org.apache.sling.commons.metrics.MetricsService as
thats added by within a DS component so tooling does not have insight into that
(SLING-7045)
[~karlpauls] [~cziegeler] Any suggestion on how to do this?
> Commons Metrics DOES not declare provide capability for Metrics service
> ---
>
> Key: SLING-6474
> URL: https://issues.apache.org/jira/browse/SLING-6474
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Affects Versions: Commons Metrics 1.2.0
>Reporter: Nino Martinez
>Assignee: Chetan Mehrotra
> Fix For: commons metrics 1.2.4
>
>
> Commons Metrics needs to declare provide capability for
> org.apache.sling.commons.metrics.MetricsService in manifest.MF
> otherwise other bundles that specifies require capability on the
> MetricsService will fail to start.
> AS of maven bundle plugin 3.2.0 this will become a problem, since they fixed
> the capabilities generation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265185#comment-16265185 ] Chetan Mehrotra commented on SLING-7043: [~cziegeler] Would it be fine to move this to next release and unblock current one? I would like to cut a release for few issues fixed so far but would not have bandwidth for addressing this issue in near future (post discussing the approaches!) > Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction > -- > > Key: SLING-7043 > URL: https://issues.apache.org/jira/browse/SLING-7043 > Project: Sling > Issue Type: Bug >Affects Versions: Commons Metrics 1.0.0 >Reporter: Carsten Ziegeler >Priority: Blocker > Fix For: commons metrics 1.2.4 > > > commons metrics provides a nice abstraction over com.codahale.metrics - > however it is exporting com.codahale.metrics.MetricRegistry which seems to > be the only way to get at registered metrics objects. Which in turn is > completely breaking the purpose of this bundle. > So we should > a) drop exporting that service and avoid leaking internal implementation > details > b) create our own version of the registry service -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7045) OSGi services should be managed by DS
[ https://issues.apache.org/jira/browse/SLING-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265183#comment-16265183 ] Chetan Mehrotra commented on SLING-7045: [~cziegeler] The 2 services are * MetricsService - Which is actually a ServiceFactory. Not sure how to do that with DS * MetricRegistry - This is more like a factory creation mode i.e. MetricsServiceImpl creates a codehale MetricRegistry instance and registers it with service registry So probably we can keep it way it is currently? > OSGi services should be managed by DS > - > > Key: SLING-7045 > URL: https://issues.apache.org/jira/browse/SLING-7045 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Carsten Ziegeler > Fix For: commons metrics 1.2.4 > > > MetricsServiceImpl is currently registering two services in its activate > method - there seems to be no real reason doing this manually and the > services should rather be registered by DS -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-5418) Display description about Metrics being collected in WebConsole Plugin
[ https://issues.apache.org/jira/browse/SLING-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-5418: --- Fix Version/s: (was: commons metrics 1.2.4) Commons Metrics 1.2.6 > Display description about Metrics being collected in WebConsole Plugin > -- > > Key: SLING-5418 > URL: https://issues.apache.org/jira/browse/SLING-5418 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: Commons Metrics 1.2.6 > > > Metrics webconsole plugin currently displays all metrics in tabular format. > It would be helpful if it can display some details about what metric data is > all about -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-6702) Make MetricsService accessible as easily as a Logger
[
https://issues.apache.org/jira/browse/SLING-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265175#comment-16265175
]
Chetan Mehrotra commented on SLING-6702:
[~bdelacretaz] Should we resolve this issue?
> Make MetricsService accessible as easily as a Logger
>
>
> Key: SLING-6702
> URL: https://issues.apache.org/jira/browse/SLING-6702
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: Commons Metrics 1.2.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: commons metrics 1.2.4
>
>
> Metrics are useful in all classes, not only OSGi components, so getting the
> {{MetricsService}} should be as useful as getting a {{Logger}} for example.
> I'll add a public {{MetricsServiceFactory}} class to our metrics module,
> usable like
> {code}
> MetricsService ms =
> MetricsServiceFactory.getMetricsService(this.getClass());
> {code}
> There's already a private {{MetricsServiceFactory}} class in that module,
> I'll rename that to {{InternalMetricsServiceFactory}} to avoid confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SLING-5419) TimeSeries data support for Metrics
[
https://issues.apache.org/jira/browse/SLING-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-5419.
Resolution: Won't Fix
Fix Version/s: (was: commons metrics 1.2.4)
With support for RRD4J Reporter this would not be of much use
> TimeSeries data support for Metrics
>
>
> Key: SLING-5419
> URL: https://issues.apache.org/jira/browse/SLING-5419
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>
> Jackrabbit has this support for {{TimeSeries}} data [1] which often proves to
> be useful to see how some metric has behaved over a period of time.
> In most cases we should rely on some external monitoring system to create
> proper time series data from metric data exposed in Sling. However at times
> such monitoring systems are not available. For such cases it should be
> possible to collect some time series data within Sling Metric implementation
> only
> [1]
> https://jackrabbit.apache.org/api/2.6/org/apache/jackrabbit/api/stats/TimeSeries.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SLING-7157) metatype.properties file must not be in OSGI-INF/metatype
[ https://issues.apache.org/jira/browse/SLING-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated SLING-7157: --- Fix Version/s: (was: JCR Registration 1.0.4) > metatype.properties file must not be in OSGI-INF/metatype > - > > Key: SLING-7157 > URL: https://issues.apache.org/jira/browse/SLING-7157 > Project: Sling > Issue Type: Bug >Affects Versions: JCR Web Console 1.0.2, JCR Registration 1.0.2, JCR > ClassLoader 3.2.2, Form Based Authentication 1.0.8, Settings 1.3.8, Commons > Threads 3.2.6, Auth Core 1.4.0, SLF4J MDC Filter 1.0.0, Authentication XING > OAuth 0.0.2, Authentication XING Login 0.0.2, URL Rewriter 0.0.2, DataSource > Provider 1.0.4, NoSQL MongoDB Resource Provider 1.1.0, Commons Log 5.0.2, > Discovery Impl 1.2.12, Discovery Oak 1.2.18, JCR Davex 1.3.8, JCR Webdav > 2.3.8, JCR Installer 3.1.26 >Reporter: Carsten Ziegeler >Priority: Blocker > Fix For: JCR Web Console 1.0.4, JCR ClassLoader 3.2.4, Form Based > Authentication 1.0.10, Settings 1.3.10, Auth Core 1.4.2, Mongo Resource > Provider 1.0.0, Authentication XING OAuth 0.0.4, Authentication XING Login > 0.0.4, DataSource Provider 1.0.4, URL Rewriter 0.0.4, Commons Log 5.0.4, > Commons Threads 3.2.10, SLF4J MDC Filter 1.0.2, JCR Webdav 2.3.10, JCR > Installer 3.1.28, Discovery Impl 1.2.14, Discovery Oak 1.2.24, JCR Davex > 1.3.12 > > > According to the spec the metatype.properties file must not be inside the > OSGI-INF/metatype directory. This is against the spec, so we should move it > to OSGI-INF/l10n > We probably should also upgrade the maven-scr-plugin for this 1.25.0 > I found the following files: > ./bundles/auth/core/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/auth/form/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/commons/log/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/commons/threads/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/extensions/discovery/impl/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/extensions/discovery/oak/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/extensions/settings/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/classloader/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/davex/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/registration/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/webconsole/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/webdav/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/auth/org.apache.sling.auth.xing.login/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/auth/org.apache.sling.auth.xing.oauth/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/datasource/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/mongodb/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/slf4j-mdc/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/startup-filter/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/urlrewriter/src/main/resources/OSGI-INF/metatype/metatype.properties > ./installer/providers/jcr/src/main/resources/OSGI-INF/metatype/metatype.properties > ./samples/path-based-rtp/src/main/resources/OSGI-INF/metatype/metatype.properties > ./samples/workspacepicker/src/main/resources/OSGI-INF/metatype/metatype.properties > ./testing/junit/core/src/main/resources/OSGI-INF/metatype/metatype.properties > ./testing/junit/healthcheck/src/main/resources/OSGI-INF/metatype/metatype.properties -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7157) metatype.properties file must not be in OSGI-INF/metatype
[ https://issues.apache.org/jira/browse/SLING-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265154#comment-16265154 ] Chetan Mehrotra commented on SLING-7157: Fixed JCR Registration with SLING-7264 > metatype.properties file must not be in OSGI-INF/metatype > - > > Key: SLING-7157 > URL: https://issues.apache.org/jira/browse/SLING-7157 > Project: Sling > Issue Type: Bug >Affects Versions: JCR Web Console 1.0.2, JCR Registration 1.0.2, JCR > ClassLoader 3.2.2, Form Based Authentication 1.0.8, Settings 1.3.8, Commons > Threads 3.2.6, Auth Core 1.4.0, SLF4J MDC Filter 1.0.0, Authentication XING > OAuth 0.0.2, Authentication XING Login 0.0.2, URL Rewriter 0.0.2, DataSource > Provider 1.0.4, NoSQL MongoDB Resource Provider 1.1.0, Commons Log 5.0.2, > Discovery Impl 1.2.12, Discovery Oak 1.2.18, JCR Davex 1.3.8, JCR Webdav > 2.3.8, JCR Installer 3.1.26 >Reporter: Carsten Ziegeler >Priority: Blocker > Fix For: JCR Web Console 1.0.4, JCR ClassLoader 3.2.4, Form Based > Authentication 1.0.10, Settings 1.3.10, Auth Core 1.4.2, Mongo Resource > Provider 1.0.0, Authentication XING OAuth 0.0.4, Authentication XING Login > 0.0.4, DataSource Provider 1.0.4, URL Rewriter 0.0.4, Commons Log 5.0.4, > Commons Threads 3.2.10, SLF4J MDC Filter 1.0.2, JCR Webdav 2.3.10, JCR > Installer 3.1.28, Discovery Impl 1.2.14, Discovery Oak 1.2.24, JCR Davex > 1.3.12 > > > According to the spec the metatype.properties file must not be inside the > OSGI-INF/metatype directory. This is against the spec, so we should move it > to OSGI-INF/l10n > We probably should also upgrade the maven-scr-plugin for this 1.25.0 > I found the following files: > ./bundles/auth/core/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/auth/form/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/commons/log/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/commons/threads/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/extensions/discovery/impl/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/extensions/discovery/oak/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/extensions/settings/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/classloader/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/davex/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/registration/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/webconsole/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/webdav/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/auth/org.apache.sling.auth.xing.login/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/auth/org.apache.sling.auth.xing.oauth/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/datasource/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/mongodb/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/slf4j-mdc/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/startup-filter/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/urlrewriter/src/main/resources/OSGI-INF/metatype/metatype.properties > ./installer/providers/jcr/src/main/resources/OSGI-INF/metatype/metatype.properties > ./samples/path-based-rtp/src/main/resources/OSGI-INF/metatype/metatype.properties > ./samples/workspacepicker/src/main/resources/OSGI-INF/metatype/metatype.properties > ./testing/junit/core/src/main/resources/OSGI-INF/metatype/metatype.properties > ./testing/junit/healthcheck/src/main/resources/OSGI-INF/metatype/metatype.properties -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-7264) Switch to OSGi annotation
[ https://issues.apache.org/jira/browse/SLING-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-7264. Resolution: Fixed > Switch to OSGi annotation > -- > > Key: SLING-7264 > URL: https://issues.apache.org/jira/browse/SLING-7264 > Project: Sling > Issue Type: Task > Components: JCR >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: JCR Registration 1.0.4 > > > Switch to official OSGi annotations -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (SLING-7264) Switch to OSGi annotation
[ https://issues.apache.org/jira/browse/SLING-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265033#comment-16265033 ] Chetan Mehrotra edited comment on SLING-7264 at 11/24/17 8:34 AM: -- Checked with Carsten offline. He suggested to also add back the service.vendor and service.description property. Done with with [commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-jcr-registration.git;a=commitdiff;h=055fc91b755cbc3bc05ce44c12e98a75b6c0482d] was (Author: chetanm): Carsten suggested to all also add back the service.vendor and service.description property. Done with with [commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-jcr-registration.git;a=commitdiff;h=055fc91b755cbc3bc05ce44c12e98a75b6c0482d] > Switch to OSGi annotation > -- > > Key: SLING-7264 > URL: https://issues.apache.org/jira/browse/SLING-7264 > Project: Sling > Issue Type: Task > Components: JCR >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: JCR Registration 1.0.4 > > > Switch to official OSGi annotations -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7264) Switch to OSGi annotation
[ https://issues.apache.org/jira/browse/SLING-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265033#comment-16265033 ] Chetan Mehrotra commented on SLING-7264: Carsten suggested to all also add back the service.vendor and service.description property. Done with with [commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-jcr-registration.git;a=commitdiff;h=055fc91b755cbc3bc05ce44c12e98a75b6c0482d] > Switch to OSGi annotation > -- > > Key: SLING-7264 > URL: https://issues.apache.org/jira/browse/SLING-7264 > Project: Sling > Issue Type: Task > Components: JCR >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: JCR Registration 1.0.4 > > > Switch to official OSGi annotations -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (SLING-7264) Switch to OSGi annotation
[ https://issues.apache.org/jira/browse/SLING-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16264951#comment-16264951 ] Chetan Mehrotra edited comment on SLING-7264 at 11/24/17 5:58 AM: -- Did changes with [commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-jcr-registration.git;a=commitdiff;h=d39cc33a8788c2c6b71dd798cfc0a514cf37bd85] [~cziegeler] Can you review the commit once? I had to add dummy methods for bindLog and unbindLog as otherwise the log service was not getting bound i.e. parent methods were not getting invoked was (Author: chetanm): Did changes with [commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-jcr-registration.git;a=commitdiff;h=d39cc33a8788c2c6b71dd798cfc0a514cf37bd85] > Switch to OSGi annotation > -- > > Key: SLING-7264 > URL: https://issues.apache.org/jira/browse/SLING-7264 > Project: Sling > Issue Type: Task > Components: JCR >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: JCR Registration 1.0.4 > > > Switch to official OSGi annotations -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7264) Switch to OSGi annotation
[ https://issues.apache.org/jira/browse/SLING-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16264951#comment-16264951 ] Chetan Mehrotra commented on SLING-7264: Did changes with [commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-jcr-registration.git;a=commitdiff;h=d39cc33a8788c2c6b71dd798cfc0a514cf37bd85] > Switch to OSGi annotation > -- > > Key: SLING-7264 > URL: https://issues.apache.org/jira/browse/SLING-7264 > Project: Sling > Issue Type: Task > Components: JCR >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: JCR Registration 1.0.4 > > > Switch to official OSGi annotations -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SLING-7264) Switch to OSGi annotation
Chetan Mehrotra created SLING-7264: -- Summary: Switch to OSGi annotation Key: SLING-7264 URL: https://issues.apache.org/jira/browse/SLING-7264 Project: Sling Issue Type: Task Components: JCR Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Fix For: JCR Registration 1.0.4 Switch to official OSGi annotations -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7157) metatype.properties file must not be in OSGI-INF/metatype
[ https://issues.apache.org/jira/browse/SLING-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16264205#comment-16264205 ] Chetan Mehrotra commented on SLING-7157: [~cziegeler] I wish to release JCR Registration 1.0.4 and see this issue referred for that. What changes do I need to make? I see metatype.properties but not metatype.xml so not sure where to refer the new location. Also this module uses old annotations but I am again not sure on how to switch to new version of annotation as there is no replacement for References, non anotation type config. So not sure if its worth effort. Can you have a look at the module and suggest how to move forward for release https://github.com/apache/sling-org-apache-sling-jcr-registration > metatype.properties file must not be in OSGI-INF/metatype > - > > Key: SLING-7157 > URL: https://issues.apache.org/jira/browse/SLING-7157 > Project: Sling > Issue Type: Bug >Affects Versions: JCR Web Console 1.0.2, JCR Registration 1.0.2, JCR > ClassLoader 3.2.2, Form Based Authentication 1.0.8, Settings 1.3.8, Commons > Threads 3.2.6, Auth Core 1.4.0, SLF4J MDC Filter 1.0.0, Authentication XING > OAuth 0.0.2, Authentication XING Login 0.0.2, URL Rewriter 0.0.2, DataSource > Provider 1.0.4, NoSQL MongoDB Resource Provider 1.1.0, Commons Log 5.0.2, > Discovery Impl 1.2.12, Discovery Oak 1.2.18, JCR Davex 1.3.8, JCR Webdav > 2.3.8, JCR Installer 3.1.26 >Reporter: Carsten Ziegeler >Priority: Blocker > Fix For: JCR Web Console 1.0.4, JCR Registration 1.0.4, JCR > ClassLoader 3.2.4, Form Based Authentication 1.0.10, Settings 1.3.10, Auth > Core 1.4.2, Mongo Resource Provider 1.0.0, Authentication XING OAuth 0.0.4, > Authentication XING Login 0.0.4, DataSource Provider 1.0.4, URL Rewriter > 0.0.4, Commons Log 5.0.4, Commons Threads 3.2.10, SLF4J MDC Filter 1.0.2, JCR > Webdav 2.3.10, JCR Installer 3.1.28, Discovery Impl 1.2.14, Discovery Oak > 1.2.24, JCR Davex 1.3.12 > > > According to the spec the metatype.properties file must not be inside the > OSGI-INF/metatype directory. This is against the spec, so we should move it > to OSGI-INF/l10n > We probably should also upgrade the maven-scr-plugin for this 1.25.0 > I found the following files: > ./bundles/auth/core/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/auth/form/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/commons/log/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/commons/threads/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/extensions/discovery/impl/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/extensions/discovery/oak/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/extensions/settings/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/classloader/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/davex/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/registration/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/webconsole/src/main/resources/OSGI-INF/metatype/metatype.properties > ./bundles/jcr/webdav/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/auth/org.apache.sling.auth.xing.login/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/auth/org.apache.sling.auth.xing.oauth/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/datasource/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/mongodb/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/slf4j-mdc/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/startup-filter/src/main/resources/OSGI-INF/metatype/metatype.properties > ./contrib/extensions/urlrewriter/src/main/resources/OSGI-INF/metatype/metatype.properties > ./installer/providers/jcr/src/main/resources/OSGI-INF/metatype/metatype.properties > ./samples/path-based-rtp/src/main/resources/OSGI-INF/metatype/metatype.properties > ./samples/workspacepicker/src/main/resources/OSGI-INF/metatype/metatype.properties > ./testing/junit/core/src/main/resources/OSGI-INF/metatype/metatype.properties > ./testing/junit/healthcheck/src/main/resources/OSGI-INF/metatype/metatype.properties -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-7263) Make RMI package optional
[
https://issues.apache.org/jira/browse/SLING-7263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-7263.
Resolution: Fixed
Marked optional with
[commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-jcr-registration.git;a=commitdiff;h=1952fb14d5337a011c922afe84c15e20a90294e2]
> Make RMI package optional
> --
>
> Key: SLING-7263
> URL: https://issues.apache.org/jira/browse/SLING-7263
> Project: Sling
> Issue Type: Improvement
> Components: JCR
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: JCR Registration 1.0.4
>
>
> org.apache.sling.jcr.registration bundle currently imports following packages
> {noformat}
> javax.jcr {version=[2.0,3)}
> javax.naming
> javax.naming.spi
> javax.transaction.xa {resolution:=optional}
> org.apache.jackrabbit.rmi.remote {version=[2.0,3)}
> org.apache.jackrabbit.rmi.server {version=[2.0,3)}
> org.apache.sling.jcr.registration {version=[1.1,1.2)}
> org.osgi.framework{version=[1.4,2)}
> org.osgi.service.component{version=[1.0,2)}
> org.osgi.service.log {version=[1.3,2)}
> {noformat}
> Due to required import for "org.apache.jackrabbit.rmi" package this bundle
> cannot be used on setups where "org.apache.jackrabbit.jackrabbit-jcr-rmi" is
> not present. To enable usage (JNDI registration part) on such setups we
> should mark these packages as optional
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SLING-7263) Make RMI package optional
[
https://issues.apache.org/jira/browse/SLING-7263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated SLING-7263:
---
Priority: Minor (was: Major)
> Make RMI package optional
> --
>
> Key: SLING-7263
> URL: https://issues.apache.org/jira/browse/SLING-7263
> Project: Sling
> Issue Type: Improvement
> Components: JCR
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: JCR Registration 1.0.4
>
>
> org.apache.sling.jcr.registration bundle currently imports following packages
> {noformat}
> javax.jcr {version=[2.0,3)}
> javax.naming
> javax.naming.spi
> javax.transaction.xa {resolution:=optional}
> org.apache.jackrabbit.rmi.remote {version=[2.0,3)}
> org.apache.jackrabbit.rmi.server {version=[2.0,3)}
> org.apache.sling.jcr.registration {version=[1.1,1.2)}
> org.osgi.framework{version=[1.4,2)}
> org.osgi.service.component{version=[1.0,2)}
> org.osgi.service.log {version=[1.3,2)}
> {noformat}
> Due to required import for "org.apache.jackrabbit.rmi" package this bundle
> cannot be used on setups where "org.apache.jackrabbit.jackrabbit-jcr-rmi" is
> not present. To enable usage (JNDI registration part) on such setups we
> should mark these packages as optional
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (SLING-7263) Make RMI package optional
Chetan Mehrotra created SLING-7263:
--
Summary: Make RMI package optional
Key: SLING-7263
URL: https://issues.apache.org/jira/browse/SLING-7263
Project: Sling
Issue Type: Improvement
Components: JCR
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Fix For: JCR Registration 1.0.4
org.apache.sling.jcr.registration bundle currently imports following packages
{noformat}
javax.jcr {version=[2.0,3)}
javax.naming
javax.naming.spi
javax.transaction.xa {resolution:=optional}
org.apache.jackrabbit.rmi.remote {version=[2.0,3)}
org.apache.jackrabbit.rmi.server {version=[2.0,3)}
org.apache.sling.jcr.registration {version=[1.1,1.2)}
org.osgi.framework{version=[1.4,2)}
org.osgi.service.component{version=[1.0,2)}
org.osgi.service.log {version=[1.3,2)}
{noformat}
Due to required import for "org.apache.jackrabbit.rmi" package this bundle
cannot be used on setups where "org.apache.jackrabbit.jackrabbit-jcr-rmi" is
not present. To enable usage (JNDI registration part) on such setups we should
mark these packages as optional
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SLING-3049) Make Logback Stacktrace Packaging data support OSGi aware
[ https://issues.apache.org/jira/browse/SLING-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-3049. Resolution: Fixed Fix Version/s: Commons Log 5.0.4 Merged the changes to master. Feature is disabled by default and can be enabled by setting config/framework property "org.apache.sling.commons.log.packagingDataEnabled" to true > Make Logback Stacktrace Packaging data support OSGi aware > - > > Key: SLING-3049 > URL: https://issues.apache.org/jira/browse/SLING-3049 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Labels: logback > Fix For: Commons Log 5.0.4 > > Attachments: SLING-3049.patch, > buildbot-exceptions-while-stopping-jetty.txt > > > Logback provides a useful feature where it dumps the Class packaging Data > along with the stacktrace [1]. This provides a quick view of the location > from where classes in a given stacktrace are coming. Its default logic does > not work properly in OSGi env. Hence it would be useful to patch its logic to > become OSGi aware > [1] http://logback.qos.ch/reasonsToSwitch.html#packagingData -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SLING-7239) LogbackManager may miss out some OSGi config at time of startup
Chetan Mehrotra created SLING-7239:
--
Summary: LogbackManager may miss out some OSGi config at time of
startup
Key: SLING-7239
URL: https://issues.apache.org/jira/browse/SLING-7239
Project: Sling
Issue Type: Bug
Components: Commons
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Fix For: Commons Log 5.0.4
{{LogbackManager}} currently upon construction reads all the OSGi config and
configure them in Logback. Config which comes laters leads to logback reset.
However during the time when its getting constructed it has a logic to ignore
the reset flag initialization for startup. This may lead to a race condition
where some OSGi configs are picked up while it is getting constructed and some
OSGi config arriving later are not picked up. For e.g.
# LogbackManager constructor is invoked
# It constructs LogConfigManager which registers the managed services
# ManagedServices receive some OSGi config and push them to LogConfigManager
# LogbackManager picks them up and add them to Logback but still startup is not
finished i.e. started = true is not called
# Some more OSGi config arrive - These would get ignored as
LogbackManager#configChanged would ignore the calls because started != true
# LogbackManager startup completes and started = true
So here configs at #5 would not be picked up unless at #7 some more OSGi config
arrive. Or some one modifies the config post system start
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-3049) Make Logback Stacktrace Packaging data support OSGi aware
[ https://issues.apache.org/jira/browse/SLING-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235466#comment-16235466 ] Chetan Mehrotra commented on SLING-3049: Thanks [~karlpauls] for the feedback bq. Obviously, it suffers a little from not being able to get to the real classes - i.e., it will not report on classes that are provided from more than one bundle Yes. If same package is loaded by multiple bundles then this impl would not provide any info. But in most cases the packages are unique so should be ok for Sling like setup bq. I guess the only question I would have is if this could be problematic for tools/scripts/others that rely on a certain layout of a stacktrace. Not sure that is important. I mostly use Intellij Stacktrace Analyzer and it is able to work with that bq. I suppose you could use some bytecode magic to weave the information about the bundle source into the "Source" field of the class and parse it out later when you need it but that probably isn't a good idea That would be really cool and nifty use of weaving hook!. But for some other day :) > Make Logback Stacktrace Packaging data support OSGi aware > - > > Key: SLING-3049 > URL: https://issues.apache.org/jira/browse/SLING-3049 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Major > Labels: logback > Attachments: SLING-3049.patch, > buildbot-exceptions-while-stopping-jetty.txt > > > Logback provides a useful feature where it dumps the Class packaging Data > along with the stacktrace [1]. This provides a quick view of the location > from where classes in a given stacktrace are coming. Its default logic does > not work properly in OSGi env. Hence it would be useful to patch its logic to > become OSGi aware > [1] http://logback.qos.ch/reasonsToSwitch.html#packagingData -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-7223) Spikes in RRD after restart
[ https://issues.apache.org/jira/browse/SLING-7223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-7223. Resolution: Fixed Assignee: Chetan Mehrotra Fix Version/s: Commons Metrics RRD4J 1.0.2 > Spikes in RRD after restart > --- > > Key: SLING-7223 > URL: https://issues.apache.org/jira/browse/SLING-7223 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Metrics RRD4J 1.0.0 >Reporter: Marcel Reutegger >Assignee: Chetan Mehrotra >Priority: Major > Fix For: Commons Metrics RRD4J 1.0.2 > > Attachments: SLING-7223.patch > > > Running the reporter for some time and then restarting the process shows > spikes in the collected data. These are caused by counter gauges that are > reset to zero after a restart. RRD interprets them as 32bit or 64bit integer > overflows and calculates incorrect values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7223) Spikes in RRD after restart
[ https://issues.apache.org/jira/browse/SLING-7223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16233656#comment-16233656 ] Chetan Mehrotra commented on SLING-7223: Done with [commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-commons-metrics-rrd4j.git;a=commitdiff;h=d6d22d0f6f431e2f9c2bf465833cf3831095636d] > Spikes in RRD after restart > --- > > Key: SLING-7223 > URL: https://issues.apache.org/jira/browse/SLING-7223 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Metrics RRD4J 1.0.0 >Reporter: Marcel Reutegger >Priority: Major > Attachments: SLING-7223.patch > > > Running the reporter for some time and then restarting the process shows > spikes in the collected data. These are caused by counter gauges that are > reset to zero after a restart. RRD interprets them as 32bit or 64bit integer > overflows and calculates incorrect values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-7222) Too frequent samples
[
https://issues.apache.org/jira/browse/SLING-7222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-7222.
Resolution: Fixed
Assignee: Chetan Mehrotra
Fix Version/s: Commons Metrics RRD4J 1.0.2
> Too frequent samples
>
>
> Key: SLING-7222
> URL: https://issues.apache.org/jira/browse/SLING-7222
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Metrics RRD4J 1.0.0
>Reporter: Marcel Reutegger
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: Commons Metrics RRD4J 1.0.2
>
> Attachments: SLING-7222.patch
>
>
> The metrics reporter sometimes logs error messages telling samples are
> reported too frequently (more than once a second):
> {noformat}
> 29.10.2017 19:01:25.384 *ERROR* [metrics-RRD4JReporter-1-thread-1]
> com.codahale.metrics.ScheduledReporter RuntimeException thrown from
> RRD4JReporter#report. Exception was suppressed.
> java.lang.IllegalArgumentException: Bad sample time: 1509300085. Last update
> time was 1509300085, at least one second step is required
> at org.rrd4j.core.RrdDb.store(RrdDb.java:517)
> at org.rrd4j.core.Sample.update(Sample.java:194)
> at
> org.apache.sling.commons.metrics.rrd4j.impl.RRD4JReporter.report(RRD4JReporter.java:239)
> at
> com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:162)
> at
> com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:117)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 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
(v6.4.14#64029)
[jira] [Commented] (SLING-7222) Too frequent samples
[
https://issues.apache.org/jira/browse/SLING-7222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16226884#comment-16226884
]
Chetan Mehrotra commented on SLING-7222:
Applied patch with
[commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-commons-metrics-rrd4j.git;a=commitdiff;h=a07550a196736d25f0593b5e5b2432db8bd39c1b]
> Too frequent samples
>
>
> Key: SLING-7222
> URL: https://issues.apache.org/jira/browse/SLING-7222
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Metrics RRD4J 1.0.0
>Reporter: Marcel Reutegger
>Priority: Minor
> Attachments: SLING-7222.patch
>
>
> The metrics reporter sometimes logs error messages telling samples are
> reported too frequently (more than once a second):
> {noformat}
> 29.10.2017 19:01:25.384 *ERROR* [metrics-RRD4JReporter-1-thread-1]
> com.codahale.metrics.ScheduledReporter RuntimeException thrown from
> RRD4JReporter#report. Exception was suppressed.
> java.lang.IllegalArgumentException: Bad sample time: 1509300085. Last update
> time was 1509300085, at least one second step is required
> at org.rrd4j.core.RrdDb.store(RrdDb.java:517)
> at org.rrd4j.core.Sample.update(Sample.java:194)
> at
> org.apache.sling.commons.metrics.rrd4j.impl.RRD4JReporter.report(RRD4JReporter.java:239)
> at
> com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:162)
> at
> com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:117)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 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
(v6.4.14#64029)
[jira] [Commented] (SLING-3049) Make Logback Stacktrace Packaging data support OSGi aware
[ https://issues.apache.org/jira/browse/SLING-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16226687#comment-16226687 ] Chetan Mehrotra commented on SLING-3049: bq. How about adding bundle + version only when it changes from the previous line? That would bit tricky to implement as current extension point to add this info is called per line. To implement this logic would need to maintain more context > Make Logback Stacktrace Packaging data support OSGi aware > - > > Key: SLING-3049 > URL: https://issues.apache.org/jira/browse/SLING-3049 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Labels: logback > Attachments: SLING-3049.patch, > buildbot-exceptions-while-stopping-jetty.txt > > > Logback provides a useful feature where it dumps the Class packaging Data > along with the stacktrace [1]. This provides a quick view of the location > from where classes in a given stacktrace are coming. Its default logic does > not work properly in OSGi env. Hence it would be useful to patch its logic to > become OSGi aware > [1] http://logback.qos.ch/reasonsToSwitch.html#packagingData -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-3049) Make Logback Stacktrace Packaging data support OSGi aware
[
https://issues.apache.org/jira/browse/SLING-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16226665#comment-16226665
]
Chetan Mehrotra commented on SLING-3049:
So with bundle name included stacktrace looks like below
{noformat}
31.10.2017 17:19:52.383 *WARN* [oak-executor-33]
org.apache.jackrabbit.oak.jcr.session.RefreshStrategy This session has been
idle for 2 minutes and might be out of date. Consider using a fresh session or
explicitly refresh the session.
java.lang.Exception: The session was created here:
at
org.apache.jackrabbit.oak.jcr.session.RefreshStrategy$LogOnce.(RefreshStrategy.java:170)
[org.apache.jackrabbit.oak-jcr:1.6.4]
at
org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:279)
[org.apache.jackrabbit.oak-jcr:1.6.4]
at
org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:220)
[org.apache.jackrabbit.oak-jcr:1.6.4]
at
org.apache.jackrabbit.oak.jcr.session.SessionImpl.impersonate(SessionImpl.java:274)
[org.apache.jackrabbit.oak-jcr:1.6.4]
at
org.apache.sling.jcr.oak.server.internal.TcclWrappingJackrabbitSession.impersonate(TcclWrappingJackrabbitSession.java:84)
[org.apache.sling.jcr.oak.server:1.1.4]
at
org.apache.sling.jcr.base.AbstractSlingRepository2.createServiceSession(AbstractSlingRepository2.java:201)
[org.apache.sling.jcr.base:3.0.4]
at
org.apache.sling.jcr.base.AbstractSlingRepository2.createServiceSession(AbstractSlingRepository2.java:171)
[org.apache.sling.jcr.base:3.0.4]
at
org.apache.sling.jcr.base.AbstractSlingRepository2.loginService(AbstractSlingRepository2.java:381)
[org.apache.sling.jcr.base:3.0.4]
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrProviderStateFactory.createProviderState(JcrProviderStateFactory.java:112)
[org.apache.sling.jcr.resource:3.0.4]
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:275)
[org.apache.sling.jcr.resource:3.0.4]
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.authenticate(JcrResourceProvider.java:74)
[org.apache.sling.jcr.resource:3.0.4]
at
org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticate(ProviderManager.java:161)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.getOrCreateProvider(ProviderManager.java:87)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.providers.stateful.ProviderManager.authenticateAll(ProviderManager.java:129)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.createControl(ResourceResolverImpl.java:138)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:100)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.(ResourceResolverImpl.java:94)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.getResourceResolverInternal(CommonResourceResolverFactoryImpl.java:263)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.CommonResourceResolverFactoryImpl.getServiceResourceResolver(CommonResourceResolverFactoryImpl.java:396)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.helper.ResourceResolverControl.getResourceTypeResourceResolver(ResourceResolverControl.java:704)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.helper.ResourceResolverControl.getParentResourceType(ResourceResolverControl.java:728)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getParentResourceType(ResourceResolverImpl.java:1216)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getParentResourceType(ResourceResolverImpl.java:1205)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.isResourceType(ResourceResolverImpl.java:1233)
[org.apache.sling.resourceresolver:1.5.30]
at
org.apache.sling.api.resource.AbstractResource.isResourceType(AbstractResource.java:121)
[org.apache.sling.api:2.16.2]
at
org.apache.sling.i18n.impl.JcrResourceBundleProvider.isDictionaryResource(JcrResourceBundleProvider.java:242)
[org.apache.sling.i18n:2.5.8]
at
org.apache.sling.i18n.impl.JcrResourceBundleProvider.onChange(JcrResourceBundleProvider.java:222)
[org.apache.sling.i18n:2.5.8]
at
org.apac
[jira] [Commented] (SLING-3049) Make Logback Stacktrace Packaging data support OSGi aware
[ https://issues.apache.org/jira/browse/SLING-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16226353#comment-16226353 ] Chetan Mehrotra commented on SLING-3049: bq. Will this be automatically part of any stacktraces in log files? Yes. We can possibly enable this feature by default also > Make Logback Stacktrace Packaging data support OSGi aware > - > > Key: SLING-3049 > URL: https://issues.apache.org/jira/browse/SLING-3049 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Labels: logback > Attachments: SLING-3049.patch, > buildbot-exceptions-while-stopping-jetty.txt > > > Logback provides a useful feature where it dumps the Class packaging Data > along with the stacktrace [1]. This provides a quick view of the location > from where classes in a given stacktrace are coming. Its default logic does > not work properly in OSGi env. Hence it would be useful to patch its logic to > become OSGi aware > [1] http://logback.qos.ch/reasonsToSwitch.html#packagingData -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7223) Spikes in RRD after restart
[ https://issues.apache.org/jira/browse/SLING-7223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16226250#comment-16226250 ] Chetan Mehrotra commented on SLING-7223: [~mreutegg] You can also send PR now with https://github.com/apache/sling-org-apache-sling-commons-metrics-rrd4j. Let me know if you want to send a PR or I should apply this patch > Spikes in RRD after restart > --- > > Key: SLING-7223 > URL: https://issues.apache.org/jira/browse/SLING-7223 > Project: Sling > Issue Type: Bug > Components: Commons >Affects Versions: Commons Metrics RRD4J 1.0.0 >Reporter: Marcel Reutegger > Attachments: SLING-7223.patch > > > Running the reporter for some time and then restarting the process shows > spikes in the collected data. These are caused by counter gauges that are > reset to zero after a restart. RRD interprets them as 32bit or 64bit integer > overflows and calculates incorrect values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-7224) Switch to standard OSGi annotations
[ https://issues.apache.org/jira/browse/SLING-7224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-7224. Resolution: Fixed Done with [commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-commons-log.git;a=commitdiff;h=d8db32c4f36f61650ab16b2c5bdc2a873b76abdc] > Switch to standard OSGi annotations > --- > > Key: SLING-7224 > URL: https://issues.apache.org/jira/browse/SLING-7224 > Project: Sling > Issue Type: Task > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: Commons Log 5.0.4 > > > Switch to official OSGi annotations -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SLING-7224) Switch to standard OSGi annotations
Chetan Mehrotra created SLING-7224: -- Summary: Switch to standard OSGi annotations Key: SLING-7224 URL: https://issues.apache.org/jira/browse/SLING-7224 Project: Sling Issue Type: Task Components: Commons Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Fix For: Commons Log 5.0.4 Switch to official OSGi annotations -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (SLING-6482) Commons Log WebConsole: Exception when creating logger with an empty log file
[
https://issues.apache.org/jira/browse/SLING-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra reassigned SLING-6482:
--
Assignee: Chetan Mehrotra
> Commons Log WebConsole: Exception when creating logger with an empty log file
> -
>
> Key: SLING-6482
> URL: https://issues.apache.org/jira/browse/SLING-6482
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Log 5.0.0
>Reporter: Bjoern Weide
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: Commons Log 5.0.4
>
> Attachments: SLING-6482-v01.patch
>
>
> When creating a new logger via WebConsole specifying an empty logfile it
> causes an StringIndexOutOfBoundsException when (re-)opening the WebConsole.
> {noformat}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1931)
> at
> org.apache.sling.commons.log.logback.internal.SlingLogPanel.getPath(SlingLogPanel.java:791)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-6482) Commons Log WebConsole: Exception when creating logger with an empty log file
[
https://issues.apache.org/jira/browse/SLING-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16226229#comment-16226229
]
Chetan Mehrotra commented on SLING-6482:
Thanks [~kwin] for the details. Fixed this with
[commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-commons-log.git;a=commitdiff;h=eb3a92d8eb454ff8091e24408d35802006ebba94].
Now an empty fileName is mapped to "console" appender. This works fine post
edits also.
[~kwin] Can you validate the behaviour once with trunk to check it addresses
your concerns.
> Commons Log WebConsole: Exception when creating logger with an empty log file
> -
>
> Key: SLING-6482
> URL: https://issues.apache.org/jira/browse/SLING-6482
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Log 5.0.0
>Reporter: Bjoern Weide
>Priority: Minor
> Fix For: Commons Log 5.0.4
>
> Attachments: SLING-6482-v01.patch
>
>
> When creating a new logger via WebConsole specifying an empty logfile it
> causes an StringIndexOutOfBoundsException when (re-)opening the WebConsole.
> {noformat}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1931)
> at
> org.apache.sling.commons.log.logback.internal.SlingLogPanel.getPath(SlingLogPanel.java:791)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (SLING-6577) StringIndexOutOfBoundsException in Sling Log Web Console when creating new logger with absolute file name
[
https://issues.apache.org/jira/browse/SLING-6577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved SLING-6577.
Resolution: Fixed
Fixed this now with
[commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-commons-log.git;a=commitdiff;h=e87cc833a4a12cd39e7798f98ab5b998374896e5]
> StringIndexOutOfBoundsException in Sling Log Web Console when creating new
> logger with absolute file name
> -
>
> Key: SLING-6577
> URL: https://issues.apache.org/jira/browse/SLING-6577
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Log 5.0.0
>Reporter: Konrad Windszus
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 5.0.4
>
>
> After adding a new logger via the web console exposed at
> {{/system/console/slinglog}} with an absolute filename (one starting with
> "/"), the following exception is thrown
> {code}
> 28.02.2017 16:47:31.300 *ERROR* [qtp455076072-280]
> org.apache.felix.http.jetty Exception while processing request to
> /system/console/slinglog (java.lang.StringIndexOutOfBoundsException: String
> index out of range: -42)
> java.lang.StringIndexOutOfBoundsException: String index out of range: -42
> at java.lang.String.substring(String.java:1931)
> at
> org.apache.sling.commons.log.logback.internal.SlingLogPanel.getPath(SlingLogPanel.java:791)
> at
> org.apache.sling.commons.log.logback.internal.SlingLogPanel.appendOsgiConfiguredLoggerData(SlingLogPanel.java:221)
> at
> org.apache.sling.commons.log.logback.internal.SlingLogPanel.render(SlingLogPanel.java:110)
> at
> org.apache.sling.commons.log.webconsole.internal.LogWebConsolePlugin.renderContent(LogWebConsolePlugin.java:79)
> at
> org.apache.felix.webconsole.AbstractWebConsolePlugin.doGet(AbstractWebConsolePlugin.java:194)
> {code}
> This is related to the exception being mentioned in SLING-6482.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (SLING-6577) StringIndexOutOfBoundsException in Sling Log Web Console when creating new logger with absolute file name
[
https://issues.apache.org/jira/browse/SLING-6577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra reassigned SLING-6577:
--
Assignee: Chetan Mehrotra
> StringIndexOutOfBoundsException in Sling Log Web Console when creating new
> logger with absolute file name
> -
>
> Key: SLING-6577
> URL: https://issues.apache.org/jira/browse/SLING-6577
> Project: Sling
> Issue Type: Bug
> Components: Commons
>Affects Versions: Commons Log 5.0.0
>Reporter: Konrad Windszus
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 5.0.4
>
>
> After adding a new logger via the web console exposed at
> {{/system/console/slinglog}} with an absolute filename (one starting with
> "/"), the following exception is thrown
> {code}
> 28.02.2017 16:47:31.300 *ERROR* [qtp455076072-280]
> org.apache.felix.http.jetty Exception while processing request to
> /system/console/slinglog (java.lang.StringIndexOutOfBoundsException: String
> index out of range: -42)
> java.lang.StringIndexOutOfBoundsException: String index out of range: -42
> at java.lang.String.substring(String.java:1931)
> at
> org.apache.sling.commons.log.logback.internal.SlingLogPanel.getPath(SlingLogPanel.java:791)
> at
> org.apache.sling.commons.log.logback.internal.SlingLogPanel.appendOsgiConfiguredLoggerData(SlingLogPanel.java:221)
> at
> org.apache.sling.commons.log.logback.internal.SlingLogPanel.render(SlingLogPanel.java:110)
> at
> org.apache.sling.commons.log.webconsole.internal.LogWebConsolePlugin.renderContent(LogWebConsolePlugin.java:79)
> at
> org.apache.felix.webconsole.AbstractWebConsolePlugin.doGet(AbstractWebConsolePlugin.java:194)
> {code}
> This is related to the exception being mentioned in SLING-6482.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-6044) Conflicting LogManager and LogWriter if using the same logfile
[
https://issues.apache.org/jira/browse/SLING-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16225046#comment-16225046
]
Chetan Mehrotra commented on SLING-6044:
[~jhoh] Understand the issue now ... so requirement is just to document it in
Sling docs. No change in current logic required?
> Conflicting LogManager and LogWriter if using the same logfile
> --
>
> Key: SLING-6044
> URL: https://issues.apache.org/jira/browse/SLING-6044
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Affects Versions: Commons Log 4.0.2
>Reporter: Jörg Hoh
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 5.0.4
>
> Attachments: SLING-6044-multiple-loggers-writers.jpg
>
>
> When you have a logmanager and a logwriter pointing to the same file, you get
> an exception like this:
> {panel}
> 07.09.2016 17:33:31.126 *ERROR* [] CM Configuration Updater (Update:
> pid=org.apache.sling.commons.log.LogManager) org.apache.felix.configadmin
> Service [org.apache.felix.cm.ConfigurationAdmin,9,
> [org.osgi.service.cm.ConfigurationAdmin]]
> [org.osgi.service.cm.ManagedService, id=10,
> bundle=7/slinginstall:c:\java\IBM\LibertyProfile\usr\servers\aem-1\sling\_\launchpad\startup\1\org.apache.sling.commons.log-4.0.0.jar]:
> Updating property org.apache.sling.commons.log.file of configuration
> org.apache.sling.commons.log.LogManager caused a problem: LogFile
> C:\java\IBM\LibertyProfile\usr\servers\aem-1\aemlogs\logs\error.log already
> configured by configuration
> org.apache.sling.commons.log.LogManager.factory.writer.8402a603-bdef-4404-9ff1-0e0f592578af
> (org.osgi.service.cm.ConfigurationException:
> org.apache.sling.commons.log.file : LogFile
> C:\java\IBM\LibertyProfile\usr\servers\aem-1\aemlogs\logs\error.log already
> configured by configuration
> org.apache.sling.commons.log.LogManager.factory.writer.8402a603-bdef-4404-9ff1-0e0f592578af)
>
> org.osgi.service.cm.ConfigurationException: org.apache.sling.commons.log.file
> : LogFile C:\java\IBM\LibertyProfile\usr\servers\aem-1\aemlogs\logs\error.log
> already configured by configuration
> org.apache.sling.commons.log.LogManager.factory.writer.8402a603-bdef-4404-9ff1-0e0f592578af
>
> at
> org.apache.sling.commons.log.logback.internal.config.GlobalConfigurator.updated(GlobalConfigurator.java:32)
> at
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:148)
>
> at
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:81)
>
> at
> org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1744)
>
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> at java.lang.Thread.run(Thread.java:744)
> Caused by:
> org.apache.sling.commons.log.logback.internal.config.ConfigurationException:
> at
> org.apache.sling.commons.log.logback.internal.LogConfigManager.updateLogWriter(LogConfigManager.java:398)
>
> at
> org.apache.sling.commons.log.logback.internal.LogConfigManager.updateGlobalConfiguration(LogConfigManager.java:327)
>
> at
> org.apache.sling.commons.log.logback.internal.config.GlobalConfigurator.updated(GlobalConfigurator.java:30)
>
> ... 5 common frames omitted
> {panel}
> Obviously the Logmanager internally provides a Logwriter, so these conflict.
> This should be documented.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-3049) Make Logback Stacktrace Packaging data support OSGi aware
[
https://issues.apache.org/jira/browse/SLING-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16223417#comment-16223417
]
Chetan Mehrotra commented on SLING-3049:
Created PR https://github.com/apache/sling-org-apache-sling-commons-log/pull/1
This approach uses a
[WeavingHook|https://osgi.org/javadoc/r4v43/core/org/osgi/framework/hooks/weaving/WeavingHook.html]
to determine class to bundle mapping. Via hook it create a mapping of class
package with bundle version. Then it hooks into the Logback rendering logic to
add the version info as part of stacktrace.
The log entry would look like below
{noformat}
28.10.2017 15:52:34.060 *ERROR* [0:0:0:0:0:0:0:1 [1509186154052] POST
/bin/cpm/nodes/node.create.json HTTP/1.1]
com.composum.sling.core.servlet.ServletOperationSet Access denied.
javax.jcr.AccessDeniedException: Access denied.
at
org.apache.jackrabbit.oak.jcr.security.AccessManager.checkPermissions(AccessManager.java:71)
[1.6.4]
at
org.apache.jackrabbit.oak.jcr.session.NodeImpl$5.perform(NodeImpl.java:295)
[1.6.4]
at
org.apache.jackrabbit.oak.jcr.session.NodeImpl$5.perform(NodeImpl.java:264)
[1.6.4]
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:208)
[1.6.4]
at
org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
[1.6.4]
at
org.apache.jackrabbit.oak.jcr.session.NodeImpl.addNode(NodeImpl.java:264)
[1.6.4]
at
com.composum.sling.nodes.servlet.NodeFactory$DefaultStrategy.createNode(NodeFactory.java:68)
[1.8.2]
at
com.composum.sling.nodes.servlet.NodeFactory.createNode(NodeFactory.java:51)
[1.8.2]
at
com.composum.sling.nodes.servlet.NodeServlet$CreateOperation.doIt(NodeServlet.java:1083)
[1.8.2]
at
com.composum.sling.core.servlet.ServletOperationSet.doPost(ServletOperationSet.java:173)
[1.8.2]
at
com.composum.sling.core.servlet.AbstractServiceServlet.doPost(AbstractServiceServlet.java:85)
[1.8.2]
at
org.apache.sling.api.servlets.SlingAllMethodsServlet.mayService(SlingAllMethodsServlet.java:149)
[2.16.2]
at
org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:346)
[2.16.2]
at
org.apache.sling.api.servlets.SlingSafeMethodsServlet.service(SlingSafeMethodsServlet.java:378)
[2.16.2]
at
org.apache.sling.engine.impl.request.RequestData.service(RequestData.java:552)
[2.6.8]
at
org.apache.sling.engine.impl.filter.SlingComponentFilterChain.render(SlingComponentFilterChain.java:44)
[2.6.8]
at
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:77)
[2.6.8]
at
org.apache.sling.engine.impl.SlingRequestProcessorImpl.processComponent(SlingRequestProcessorImpl.java:282)
[2.6.8]
at
org.apache.sling.engine.impl.filter.RequestSlingFilterChain.render(RequestSlingFilterChain.java:49)
[2.6.8]
at
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:77)
[2.6.8]
at
org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter.doFilter(RequestProgressTrackerLogFilter.java:107)
[2.6.8]
at
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:68)
[2.6.8]
at org.apache.sling.i18n.impl.I18NFilter.doFilter(I18NFilter.java:138)
[2.5.8]
{noformat}
With this feature enabled on a larger setup I did not find any delay in
startup/restart. On such a setup it was having mapping for 2000+ packages. This
approach does not add much over head as mapping is cached.
[~karlpauls] [~cziegeler] [~ianeboston] Please review the approach. This
feature should not be adding much overhead and would prove useful when users
provide exception message on mailing list to discuss the issue.
PS: If required we can also include bundle name. But that may not be very useful
> Make Logback Stacktrace Packaging data support OSGi aware
> -
>
> Key: SLING-3049
> URL: https://issues.apache.org/jira/browse/SLING-3049
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Labels: logback
> Attachments: SLING-3049.patch,
> buildbot-exceptions-while-stopping-jetty.txt
>
>
> Logback provides a useful feature where it dumps the Class packaging Data
> along with the stacktrace [1]. This provides a quick view of the location
> from where classes in a given stacktrace are coming. Its default logic does
> not work properly in OSGi env. Hence it would be useful to patch its logic to
> become OSGi aware
> [1] http://logback.qos.ch/reasonsToSwitch.html#packagingData
--
This message was s
[jira] [Reopened] (SLING-3049) Make Logback Stacktrace Packaging data support OSGi aware
[ https://issues.apache.org/jira/browse/SLING-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra reopened SLING-3049: > Make Logback Stacktrace Packaging data support OSGi aware > - > > Key: SLING-3049 > URL: https://issues.apache.org/jira/browse/SLING-3049 > Project: Sling > Issue Type: Improvement > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Labels: logback > Attachments: SLING-3049.patch, > buildbot-exceptions-while-stopping-jetty.txt > > > Logback provides a useful feature where it dumps the Class packaging Data > along with the stacktrace [1]. This provides a quick view of the location > from where classes in a given stacktrace are coming. Its default logic does > not work properly in OSGi env. Hence it would be useful to patch its logic to > become OSGi aware > [1] http://logback.qos.ch/reasonsToSwitch.html#packagingData -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-7221) Update osgi core dependency to 6.0
[ https://issues.apache.org/jira/browse/SLING-7221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-7221. Resolution: Fixed Done with [commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-commons-log.git;a=commitdiff;h=4df7eb1af0e9575d8b9348ab0362acfe03d03c5e;hp=48675f2477d848f00faa652b5c1d1a45ac6dad4b] > Update osgi core dependency to 6.0 > -- > > Key: SLING-7221 > URL: https://issues.apache.org/jira/browse/SLING-7221 > Project: Sling > Issue Type: Task > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: Commons Log 5.0.4 > > > Update various dependencies in Commons Log. Particularly dependency on > osgi.core to 6.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SLING-7221) Update osgi core dependency to 6.0
Chetan Mehrotra created SLING-7221: -- Summary: Update osgi core dependency to 6.0 Key: SLING-7221 URL: https://issues.apache.org/jira/browse/SLING-7221 Project: Sling Issue Type: Task Components: Commons Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Fix For: Commons Log 5.0.4 Update various dependencies in Commons Log. Particularly dependency on osgi.core to 6.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-7220) Update Logback to 1.2.3 version
[ https://issues.apache.org/jira/browse/SLING-7220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved SLING-7220. Resolution: Fixed > Update Logback to 1.2.3 version > --- > > Key: SLING-7220 > URL: https://issues.apache.org/jira/browse/SLING-7220 > Project: Sling > Issue Type: Task > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: Commons Log 5.0.4 > > > Update Logback to 1.2.3 version > See https://logback.qos.ch/news.html for release notes. Specially 1.2.0 > release has significant performance improvements -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7220) Update Logback to 1.2.3 version
[ https://issues.apache.org/jira/browse/SLING-7220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16223255#comment-16223255 ] Chetan Mehrotra commented on SLING-7220: Done with [commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-commons-log.git;a=commitdiff;h=48675f2477d848f00faa652b5c1d1a45ac6dad4b;hp=34a0b4820df95dad2130cd9b70ab5d9a5b17a48f] > Update Logback to 1.2.3 version > --- > > Key: SLING-7220 > URL: https://issues.apache.org/jira/browse/SLING-7220 > Project: Sling > Issue Type: Task > Components: Commons >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: Commons Log 5.0.4 > > > Update Logback to 1.2.3 version > See https://logback.qos.ch/news.html for release notes. Specially 1.2.0 > release has significant performance improvements -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SLING-7220) Update Logback to 1.2.3 version
Chetan Mehrotra created SLING-7220: -- Summary: Update Logback to 1.2.3 version Key: SLING-7220 URL: https://issues.apache.org/jira/browse/SLING-7220 Project: Sling Issue Type: Task Components: Commons Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Fix For: Commons Log 5.0.4 Update Logback to 1.2.3 version See https://logback.qos.ch/news.html for release notes. Specially 1.2.0 release has significant performance improvements -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-6044) Conflicting LogManager and LogWriter if using the same logfile
[
https://issues.apache.org/jira/browse/SLING-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16223241#comment-16223241
]
Chetan Mehrotra commented on SLING-6044:
[~jhoh] Can you reproduce the issue with current Sling version? Otherwise we
can close this issue
> Conflicting LogManager and LogWriter if using the same logfile
> --
>
> Key: SLING-6044
> URL: https://issues.apache.org/jira/browse/SLING-6044
> Project: Sling
> Issue Type: Improvement
> Components: Commons
>Affects Versions: Commons Log 4.0.2
>Reporter: Jörg Hoh
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 5.0.4
>
> Attachments: SLING-6044-multiple-loggers-writers.jpg
>
>
> When you have a logmanager and a logwriter pointing to the same file, you get
> an exception like this:
> {panel}
> 07.09.2016 17:33:31.126 *ERROR* [] CM Configuration Updater (Update:
> pid=org.apache.sling.commons.log.LogManager) org.apache.felix.configadmin
> Service [org.apache.felix.cm.ConfigurationAdmin,9,
> [org.osgi.service.cm.ConfigurationAdmin]]
> [org.osgi.service.cm.ManagedService, id=10,
> bundle=7/slinginstall:c:\java\IBM\LibertyProfile\usr\servers\aem-1\sling\_\launchpad\startup\1\org.apache.sling.commons.log-4.0.0.jar]:
> Updating property org.apache.sling.commons.log.file of configuration
> org.apache.sling.commons.log.LogManager caused a problem: LogFile
> C:\java\IBM\LibertyProfile\usr\servers\aem-1\aemlogs\logs\error.log already
> configured by configuration
> org.apache.sling.commons.log.LogManager.factory.writer.8402a603-bdef-4404-9ff1-0e0f592578af
> (org.osgi.service.cm.ConfigurationException:
> org.apache.sling.commons.log.file : LogFile
> C:\java\IBM\LibertyProfile\usr\servers\aem-1\aemlogs\logs\error.log already
> configured by configuration
> org.apache.sling.commons.log.LogManager.factory.writer.8402a603-bdef-4404-9ff1-0e0f592578af)
>
> org.osgi.service.cm.ConfigurationException: org.apache.sling.commons.log.file
> : LogFile C:\java\IBM\LibertyProfile\usr\servers\aem-1\aemlogs\logs\error.log
> already configured by configuration
> org.apache.sling.commons.log.LogManager.factory.writer.8402a603-bdef-4404-9ff1-0e0f592578af
>
> at
> org.apache.sling.commons.log.logback.internal.config.GlobalConfigurator.updated(GlobalConfigurator.java:32)
> at
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:148)
>
> at
> org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:81)
>
> at
> org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1744)
>
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> at java.lang.Thread.run(Thread.java:744)
> Caused by:
> org.apache.sling.commons.log.logback.internal.config.ConfigurationException:
> at
> org.apache.sling.commons.log.logback.internal.LogConfigManager.updateLogWriter(LogConfigManager.java:398)
>
> at
> org.apache.sling.commons.log.logback.internal.LogConfigManager.updateGlobalConfiguration(LogConfigManager.java:327)
>
> at
> org.apache.sling.commons.log.logback.internal.config.GlobalConfigurator.updated(GlobalConfigurator.java:30)
>
> ... 5 common frames omitted
> {panel}
> Obviously the Logmanager internally provides a Logwriter, so these conflict.
> This should be documented.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7164) Set up the sling aggregator repository
[
https://issues.apache.org/jira/browse/SLING-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16220001#comment-16220001
]
Chetan Mehrotra commented on SLING-7164:
I initially faced issue due to presence of python 3.
{noformat}
$ repo init --no-clone-bundle -u https://github.com/apache/sling-aggregator.git
warning: Python 3 support is currently experimental. YMMV.
Please use Python 2.6 - 2.7 instead.
Traceback (most recent call last):
File "/home/chetanm/bin/repo", line 883, in
main(sys.argv[1:])
File "/home/chetanm/bin/repo", line 851, in main
_Init(args, gitc_init=(cmd == 'gitc-init'))
File "/home/chetanm/bin/repo", line 337, in _Init
_CheckGitVersion()
File "/home/chetanm/bin/repo", line 391, in _CheckGitVersion
ver_act = ParseGitVersion(ver_str)
File "/home/chetanm/bin/repo", line 361, in ParseGitVersion
if not ver_str.startswith('git version '):
TypeError: startswith first arg must be bytes or a tuple of bytes, not str
{noformat}
So had to modify the repo shebang line to explicitly use python2.7 to get going
{noformat}
- #!/usr/bin/env python
+ #!/usr/bin/env python2.7
{noformat}
> Set up the sling aggregator repository
> --
>
> Key: SLING-7164
> URL: https://issues.apache.org/jira/browse/SLING-7164
> Project: Sling
> Issue Type: Sub-task
> Components: Best practices
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Attachments: sling-aggregate.zip
>
>
> This repository should replace the current 'sling' repo as an entry point. It
> should contain a repo manifest ( or similar ) to allow checking out all the
> sling modules and maybe even regenerate a reactor pom.xml file for quick
> operations.
> The README should explain a bit more about Sling and our SCM setup and point
> to the sling home page.
> Also we should update the 'Getting and building Sling' page while we're at it
> -
> http://sling.apache.org/documentation/development/getting-and-building-sling.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-7047) Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.
[ https://issues.apache.org/jira/browse/SLING-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16135022#comment-16135022 ] Chetan Mehrotra commented on SLING-7047: bq. with that hand crafted import statement if a client sees this issue, updates to commons metrics 1.2.4 this issue is not resolved and there is no indication that you also have to update another bundle. If the client read the issue then he also sees a reference to update Dropwizard Metrics bundle to 3.2.! So should not be much of an issue. But yes having OSGi import resolution failing would be a better indicator of the requirement > Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency. > -- > > Key: SLING-7047 > URL: https://issues.apache.org/jira/browse/SLING-7047 > Project: Sling > Issue Type: Task >Reporter: Ian Boston >Assignee: Chetan Mehrotra > Fix For: commons metrics 1.2.4, Launchpad Builder 10 > > > as per https://github.com/ieb/slingmetrics/issues/1 > Not certain where the Dropwizard Metrics bundle is included, but it would be > good to make it work for any JDK, not just the Sun/Oracle JDK. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (SLING-7047) Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.
[ https://issues.apache.org/jira/browse/SLING-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134994#comment-16134994 ] Chetan Mehrotra edited comment on SLING-7047 at 8/21/17 10:16 AM: -- bq. This issue says commons metrics 1.2.4 has no dependency on sun.misc anymore - which is wrong; it still works with dropwizard 3.1, so it implicitely has this dependency Thats going into nitty gritty. Commons Metrics 1.2.4 can work with either of Metrics 3.1.0 or 3.2.x. So it does not enforce requirement of sun.misc. If setup has Metrics 3.2.x then sun.misc is not required. Anyways I would remove that import statement Update - Removed the import statement with 1805618 was (Author: chetanm): bq. This issue says commons metrics 1.2.4 has no dependency on sun.misc anymore - which is wrong; it still works with dropwizard 3.1, so it implicitely has this dependency Thats going into nitty gritty. Commons Metrics 1.2.4 can work with either of Metrics 3.1.0 or 3.2.x. So it does not enforce requirement of sun.misc. If setup has Metrics 3.2.x then sun.misc is not required. Anyways I would remove that import statement > Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency. > -- > > Key: SLING-7047 > URL: https://issues.apache.org/jira/browse/SLING-7047 > Project: Sling > Issue Type: Task >Reporter: Ian Boston >Assignee: Chetan Mehrotra > Fix For: commons metrics 1.2.4, Launchpad Builder 10 > > > as per https://github.com/ieb/slingmetrics/issues/1 > Not certain where the Dropwizard Metrics bundle is included, but it would be > good to make it work for any JDK, not just the Sun/Oracle JDK. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7047) Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.
[ https://issues.apache.org/jira/browse/SLING-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134994#comment-16134994 ] Chetan Mehrotra commented on SLING-7047: bq. This issue says commons metrics 1.2.4 has no dependency on sun.misc anymore - which is wrong; it still works with dropwizard 3.1, so it implicitely has this dependency Thats going into nitty gritty. Commons Metrics 1.2.4 can work with either of Metrics 3.1.0 or 3.2.x. So it does not enforce requirement of sun.misc. If setup has Metrics 3.2.x then sun.misc is not required. Anyways I would remove that import statement > Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency. > -- > > Key: SLING-7047 > URL: https://issues.apache.org/jira/browse/SLING-7047 > Project: Sling > Issue Type: Task >Reporter: Ian Boston >Assignee: Chetan Mehrotra > Fix For: commons metrics 1.2.4, Launchpad Builder 10 > > > as per https://github.com/ieb/slingmetrics/issues/1 > Not certain where the Dropwizard Metrics bundle is included, but it would be > good to make it work for any JDK, not just the Sun/Oracle JDK. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7047) Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency.
[ https://issues.apache.org/jira/browse/SLING-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16134968#comment-16134968 ] Chetan Mehrotra commented on SLING-7047: bq. How do we ensure that we don't use 3.2 API? Yeah that would be tricky (no automated check). I was thinking to remove that once 1.2.4 version is released as that would allow the bundle to be usable on older setup. Would that be ok? > Update Dropwizard Metrics bundles to 3.2 to eliminate sun.misc dependency. > -- > > Key: SLING-7047 > URL: https://issues.apache.org/jira/browse/SLING-7047 > Project: Sling > Issue Type: Task >Reporter: Ian Boston >Assignee: Chetan Mehrotra > Fix For: commons metrics 1.2.4, Launchpad Builder 10 > > > as per https://github.com/ieb/slingmetrics/issues/1 > Not certain where the Dropwizard Metrics bundle is included, but it would be > good to make it work for any JDK, not just the Sun/Oracle JDK. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
