Re: [github-digest] 2019-09-17 - 2019-10-02

[Chetan Mehrotra]

Hi Team,

Recently we open sourced a tooling [1] to generate Github summary report
across multiple repositories. This helps in understanding the work being
done in a project when it is split in multiple repositories

If below report is useful to the community then we enable a task to send
such a report say weekly or bi-weekly.

Chetan Mehrotra
[1] https://github.com/adobe/github-reporter


On Wed, Oct 2, 2019 at 7:24 PM Chetan Mehrotra 
wrote:

>
> apache/sling-org-apache-sling-distribution-journal Pull Requests Created:
>
>- SLING-8751 - Webconsole plugin to download content packages #12
>
> <https://github.com/apache/sling-org-apache-sling-distribution-journal/pull/12>
>(cschneider <https://github.com/cschneider>)
>
> apache/sling-org-apache-sling-dynamic-include Pull Requests Updated:
>
>- add Forward filter scope to CacheControlFilter #11
><https://github.com/apache/sling-org-apache-sling-dynamic-include/pull/11>
>(ericvangeem <https://github.com/ericvangeem>)
>
> apache/sling-org-apache-sling-event Pull Requests Created:
>
>- SLING-8665: Adds metrics for jobs #7
><https://github.com/apache/sling-org-apache-sling-event/pull/7> (
>bjoernweide <https://github.com/bjoernweide>)
>
> apache/sling-org-apache-sling-models-impl Pull Requests Created:
>
>- SLING-8754 when possible use ServiceCache #15
><https://github.com/apache/sling-org-apache-sling-models-impl/pull/15>
>(npeltier <https://github.com/npeltier>)
>
> apache/sling-org-apache-sling-scripting-jsp Pull Requests Merged:
>
>- SLING-8720 : HTTP Status 200 returned when JSP Engine fails due to
>Js… #1
><https://github.com/apache/sling-org-apache-sling-scripting-jsp/pull/1>
>(ashokpanghal <https://github.com/ashokpanghal>)
>
> apache/sling-org-apache-sling-testing-clients Pull Requests Merged:
>
>- SLING-8710: IndexingClient should have configurable lanes #11
><https://github.com/apache/sling-org-apache-sling-testing-clients/pull/11>
>(catholicon <https://github.com/catholicon>)
>
> Closed:
>
>- SLING-8727: Fix NPE in SlingClient constructor #12
><https://github.com/apache/sling-org-apache-sling-testing-clients/pull/12>
>(volteanu <https://github.com/volteanu>)
>
> apache/sling-org-apache-sling-testing-sling-mock Pull Requests Merged:
>
>- Fix NoClassDefFoundError: ScriptEngineManagerFactory #3
>
> <https://github.com/apache/sling-org-apache-sling-testing-sling-mock/pull/3>
>(stoerr <https://github.com/stoerr>)
>
> apache/sling-org-apache-sling-testing-sling-mock-oak Pull Requests Merged:
>
>- SLING-8625 update oak version to 1.16.0, jackrabbit version to
>2.18.2 #1
>
> <https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/1>
>(stefanseifert <https://github.com/stefanseifert>)
>
> apache/sling-site Pull Requests Created:
>
>- SLING-8748: running the ConfigurationClassScannerPlugin with BND #40
><https://github.com/apache/sling-site/pull/40> (joerghoh
><https://github.com/joerghoh>)
>
> apache/sling-slingfeature-maven-plugin Pull Requests Merged:
>
>- SLING-8739 Add the ability to extract extensions from a Feature
>Model #40
><https://github.com/apache/sling-slingfeature-maven-plugin/pull/40> (
>bosschaert <https://github.com/bosschaert>)
>- SLING-8692 Slingfeature maven plugin: add option to decompress
>artifacts stored in the repository goal #39
><https://github.com/apache/sling-slingfeature-maven-plugin/pull/39> (
>bosschaert <https://github.com/bosschaert>)
>
> apache/sling-whiteboard Pull Requests Merged:
>
>- SlingModelPersistor: Improvements for compatibility and additional
>Ignore features, several bug fixes #46
><https://github.com/apache/sling-whiteboard/pull/46> (badvision
><https://github.com/badvision>)
>
>

[github-digest] 2019-09-17 - 2019-10-02

[Chetan Mehrotra]

apache/sling-org-apache-sling-distribution-journal Pull Requests Created:

   - SLING-8751 - Webconsole plugin to download content packages #12
   

   (cschneider )

apache/sling-org-apache-sling-dynamic-include Pull Requests Updated:

   - add Forward filter scope to CacheControlFilter #11
   
   (ericvangeem )

apache/sling-org-apache-sling-event Pull Requests Created:

   - SLING-8665: Adds metrics for jobs #7
    (
   bjoernweide )

apache/sling-org-apache-sling-models-impl Pull Requests Created:

   - SLING-8754 when possible use ServiceCache #15
    (
   npeltier )

apache/sling-org-apache-sling-scripting-jsp Pull Requests Merged:

   - SLING-8720 : HTTP Status 200 returned when JSP Engine fails due to Js…
   #1
    (
   ashokpanghal )

apache/sling-org-apache-sling-testing-clients Pull Requests Merged:

   - SLING-8710: IndexingClient should have configurable lanes #11
   
   (catholicon )

Closed:

   - SLING-8727: Fix NPE in SlingClient constructor #12
   
   (volteanu )

apache/sling-org-apache-sling-testing-sling-mock Pull Requests Merged:

   - Fix NoClassDefFoundError: ScriptEngineManagerFactory #3
   
   (stoerr )

apache/sling-org-apache-sling-testing-sling-mock-oak Pull Requests Merged:

   - SLING-8625 update oak version to 1.16.0, jackrabbit version to 2.18.2
   #1
   

   (stefanseifert )

apache/sling-site Pull Requests Created:

   - SLING-8748: running the ConfigurationClassScannerPlugin with BND #40
    (joerghoh
   )

apache/sling-slingfeature-maven-plugin Pull Requests Merged:

   - SLING-8739 Add the ability to extract extensions from a Feature Model
   #40  (
   bosschaert )
   - SLING-8692 Slingfeature maven plugin: add option to decompress
   artifacts stored in the repository goal #39
    (
   bosschaert )

apache/sling-whiteboard Pull Requests Merged:

   - SlingModelPersistor: Improvements for compatibility and additional
   Ignore features, several bug fixes #46
    (badvision
   )

Re: Apache Felix Logback vs Sling Commons Log

[Chetan Mehrotra]

Felix Logback currently supports configuring via logback.xml config
file and if logging needs to be changed then that file would need to
be modified. Compared to that Sling Commons Logback [1] support some
more features and enables configuring appenders via OSGi config and
has a good Web Console integration.

> if it makes sense to try and converge the two
> modules into a single one, presumably in Apache Felix, as it does not
> depend on Sling and can get more community exposure.

+1

Implementation wise Commons Log does not depend on any Sling feature
(except using sling.home to configure base log directory). So it makes
sense to converge the two


Chetan Mehrotra
[1] http://sling.apache.org/documentation/development/logging.html


On Tue, Jul 10, 2018 at 7:59 PM, Karl Pauls  wrote:
> I was thinking about that too - it might make some sense to look into
> the log.extension as well as we might be able to package logback with
> the launchpad.base and have logging via logback even at framework
> start-up this way.
>
> That said, I don't know enough about our current logging features to
> say if this is enough to replace what we have. Certainly would be nice
> to remove the circular dependencies we currently have in the logging.
>
> regards,
>
> Karl
> On Tue, Jul 10, 2018 at 3:42 PM Robert Munteanu  wrote:
>>
>> Hi,
>>
>> I noticed that a logback module was recently released in the Felix
>> project [1].
>>
>> At a glance it seems to have the same high-level objectives as our own
>> commons-log implementation, but lacks a number of feature we've built.
>>
>> Since I'm not that familiar with the codebase, I would like to ask if
>> the goals are similar and if it makes sense to try and converge the two
>> modules into a single one, presumably in Apache Felix, as it does not
>> depend on Sling and can get more community exposure.
>>
>> Thanks,
>>
>> Robert
>>
>> [1]: http://felix.apache.org/documentation/subprojects/apache-felix-log
>> back.html
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com

Re: Limited search and find a file after git repo split

[Chetan Mehrotra]

At times I have used sourcegraph to search across repos like
https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/apache/sling-*++file:pom.xml.
It seems to pickup most of the repo matching given pattern
Chetan Mehrotra


On Wed, Jul 11, 2018 at 3:10 AM, Alexander Klimetschek
 wrote:
> Thanks!
>
>> On 29.06.2018, at 12:50, Daniel Klco  wrote:
>>
>> Okay, I had a minute so I made a quick tweak, adding in a paragraph with a
>> link to the aggregator and modules list:
>>
>> https://github.com/apache/sling-old-svn-mirror
>>
>> On Fri, Jun 29, 2018 at 3:39 PM Daniel Klco  wrote:
>>
>>> I'm not sure we can do much about the old svn mirror being indexed, but
>>> adding a link to the Sling Aggregator sure would help.
>>>
>>> On Fri, Jun 29, 2018 at 3:30 PM Alexander Klimetschek
>>>  wrote:
>>>
>>>> It seems nothing has really improved :) I just ended up on
>>>> https://github.com/apache/sling-old-svn-mirror, trying to find sources
>>>> from Sling, but really have no clue where it is, and the links on that
>>>> readme don't help at all.
>>>>
>>>> Cheers,
>>>> Alex
>>>>
>>>>> On 02.02.2018, at 19:12, Alexander Klimetschek
>>>>  wrote:
>>>>>
>>>>> On 30.01.2018, at 23:41, Robert Munteanu  wrote:
>>>>>> After a quick look at the github pages my only suggestion is using the
>>>>>> advanced search page
>>>>>>
>>>>>> https://github.com/search/advanced
>>>>>>
>>>>>> and filling in all the sling repos in the repo field. The search would
>>>>>> then be something like this
>>>>>>
>>>>>> org:apache repo:org-apache-sling-api ResourceResolver
>>>>>>
>>>>>> Unfortunately it does not seem to work :-( .
>>>>>
>>>>> Too many repos :)
>>>>>
>>>>> The root problem I think is that all apache projects are under one
>>>> github organization. A github org is the natural place for multi-repository
>>>> projects, and most features like search work well across all repos in one
>>>> org.
>>>>>
>>>>> Maybe the ASF can be persuaded to support "apache-"
>>>> organizations, with github somehow locking the "apache-*" namespace.
>>>> Although I doubt this would ever happen.
>>>>>
>>>>> Cheers,
>>>>> Alex
>>>>>
>>>>
>>>>
>

[jira] [Commented] (SLING-2463) Sling Script Console Plugin

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

Re: [VOTE] Release Apache Sling Commons Log 5.1.8

[Chetan Mehrotra]

+1
Chetan Mehrotra


On Sun, May 20, 2018 at 7:51 PM, Daniel Klco <dk...@apache.org> wrote:
> +1
>
> On Sun, May 20, 2018, 7:23 AM Julian Sedding <jsedd...@gmail.com> wrote:
>
>> Here's my +1.
>>
>> Regards
>> Julian
>>
>> On Sun, May 20, 2018 at 1:22 PM, Julian Sedding <jsedd...@gmail.com>
>> wrote:
>> > Hi,
>> >
>> > We solved 1 issue in the Apache Sling Commons Log 5.1.8 release:
>> > https://issues.apache.org/jira/projects/SLING/versions/12343098
>> >
>> > Staging repository:
>> > https://repository.apache.org/content/repositories/orgapachesling-1909/
>> >
>> > You can use this UNIX script to download the release and verify the
>> signatures:
>> > http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>> >
>> > Usage:
>> > sh check_staged_release.sh 1909 /tmp/sling-staging
>> >
>> > Please vote to approve this release:
>> >
>> >   [ ] +1 Approve the release
>> >   [ ]  0 Don't care
>> >   [ ] -1 Don't release, because ...
>> >
>> > This majority vote is open for at least 72 hours.
>> >
>> > Regards
>> > Julian
>>

[jira] [Commented] (SLING-7660) LogManager configuration "Number of Log Files" limited to 20

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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)

[RESULT] [VOTE] Release Apache Sling Commons Log 5.1.4

[Chetan Mehrotra]

Hi,

The vote has passed with the following result :

+1 (binding): Stefan Seifert, Carsten Ziegeler, Daniel Klco, Chetan Mehrotra

I will copy this release to the Sling dist directory and promote the
artifacts to the central Maven repository.

Chetan Mehrotra

[VOTE] Release Apache Sling Commons Log 5.1.4

[Chetan Mehrotra]

Hi,

We solved 1 issues in this release:
https://issues.apache.org/jira/projects/SLING/versions/12342892

There is 1 unsolved issue:
https://issues.apache.org/jira/browse/SLING-7529

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1890/

You can use this UNIX script to download the release and verify the signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD

Usage:
sh check_staged_release.sh 1890 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.
Chetan Mehrotra

[jira] [Resolved] (SLING-7529) Log message layouts are not property inherited

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (JIRA)]

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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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)

[RESULT][VOTE] Release Apache Sling Log Tracer 1.0.6

[Chetan Mehrotra]

Hi,

The release passes with 4 binding +1 votes from: Stefan Seifert, Karl
Pauls, and Daniel Klco.

Chetan Mehrotra

Re: [VOTE] Release Apache Sling Log Tracer 1.0.6

[Chetan Mehrotra]

Correction - We solved 1 issue in this release

+1 Approve the releases
Chetan Mehrotra


On Wed, Jan 3, 2018 at 4:58 PM, Chetan Mehrotra
<chetan.mehro...@gmail.com> wrote:
> I would like to call a vote on the following release,
>
> Apache Sling Log Tracer 1.0.6
>
> We solved 2 issue in this release:
> https://issues.apache.org/jira/projects/SLING/versions/12340678
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1842/
>
> You can use this UNIX script to download the release and verify the 
> signatures:
> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1842 /tmp/sling-staging
>
> Please vote to approve these releases:
>
>   [ ] +1 Approve the releases
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> regards
> Chetan Mehrotra

[VOTE] Release Apache Sling Log Tracer 1.0.6

[Chetan Mehrotra]

I would like to call a vote on the following release,

Apache Sling Log Tracer 1.0.6

We solved 2 issue in this release:
https://issues.apache.org/jira/projects/SLING/versions/12340678

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1842/

You can use this UNIX script to download the release and verify the signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1842 /tmp/sling-staging

Please vote to approve these releases:

  [ ] +1 Approve the releases
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

regards
Chetan Mehrotra

[jira] [Resolved] (SLING-7348) Switch to OSGi annotation for Tracer bundle

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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 (JIRA)]

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.

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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)

[RESULT] [VOTE] Release Apache Sling Commons Metrics 1.2.4

[Chetan Mehrotra]

Hi,

The vote has passed with the following result :

+1 (binding): Carsten, Bertrand, Karl and Chetan.

I will copy and release to the Sling dist directory and promote the
artifacts to the central Maven repository.

Regards
Chetan Mehrotra

Re: [VOTE] Release Apache Sling Commons Metrics 1.2.4

[Chetan Mehrotra]

+1
Chetan Mehrotra


On Mon, Dec 4, 2017 at 3:16 AM, Karl Pauls <karlpa...@gmail.com> wrote:
> +1
>
> regards,
>
> Karl
>
> On Fri, Dec 1, 2017 at 6:32 PM, Bertrand Delacretaz
> <bdelacre...@apache.org> wrote:
>> On Fri, Dec 1, 2017 at 12:03 PM, Chetan Mehrotra <chet...@apache.org> wrote:
>>>... Staging repository:
>>> https://repository.apache.org/content/repositories/orgapachesling-1823 ...
>>
>> +1, checked signatures, digests and build.
>>
>> -Bertrand
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com

[VOTE] Release Apache Sling Commons Metrics 1.2.4

[Chetan Mehrotra]

Hi,

We solved 5 issues in this release:
https://issues.apache.org/jira/projects/SLING/versions/12340679

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1823

You can use this UNIX script to download the release and verify the
signatures:
https://raw.githubusercontent.com/apache/sling-tooling-release/master/check_staged_release.sh

Usage:
sh check_staged_release.sh 1823 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

regards
Chetan

[jira] [Updated] (SLING-6474) Commons Metrics DOES not declare provide capability for Metrics service

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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 (JIRA)]

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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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)

Re: [VOTE] Release Apache Sling Commons Log 5.1.0

[Chetan Mehrotra]

 The vote passed with four binding +1 votes
Chetan Mehrotra


On Fri, Dec 1, 2017 at 11:54 AM, Chetan Mehrotra
<chetan.mehro...@gmail.com> wrote:
> +1
> Chetan Mehrotra
>
>
> On Tue, Nov 28, 2017 at 2:39 PM, Karl Pauls <karlpa...@gmail.com> wrote:
>> +1
>>
>> regards,
>>
>> Karl
>>
>> On Monday, November 27, 2017, Stefan Seifert <sseif...@pro-vision.de> wrote:
>>
>>> +1
>>>
>>>
>>
>> --
>> Karl Pauls
>> karlpa...@gmail.com

Re: [VOTE] Release Apache Sling Metrics RRD4J 1.0.2

[Chetan Mehrotra]

 The vote passed with three binding +1 votes
Chetan Mehrotra


On Fri, Dec 1, 2017 at 11:54 AM, Chetan Mehrotra
<chetan.mehro...@gmail.com> wrote:
> +1
> Chetan Mehrotra
>
>
> On Fri, Nov 24, 2017 at 8:09 PM, Karl Pauls <karlpa...@gmail.com> wrote:
>> +1
>>
>> regards,
>>
>> Karl
>>
>> On Fri, Nov 24, 2017 at 3:25 PM, Robert Munteanu <romb...@apache.org> wrote:
>>> On Fri, 2017-11-24 at 16:55 +0530, Chetan Mehrotra wrote:
>>>> Please vote to approve this release:
>>>
>>> +1
>>>
>>> Robert
>>
>>
>>
>> --
>> Karl Pauls
>> karlpa...@gmail.com

Re: [VOTE] Release Apache Sling Metrics RRD4J 1.0.2

[Chetan Mehrotra]

+1
Chetan Mehrotra


On Fri, Nov 24, 2017 at 8:09 PM, Karl Pauls <karlpa...@gmail.com> wrote:
> +1
>
> regards,
>
> Karl
>
> On Fri, Nov 24, 2017 at 3:25 PM, Robert Munteanu <romb...@apache.org> wrote:
>> On Fri, 2017-11-24 at 16:55 +0530, Chetan Mehrotra wrote:
>>> Please vote to approve this release:
>>
>> +1
>>
>> Robert
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com

Re: [VOTE] Release Apache Sling Commons Log 5.1.0

[Chetan Mehrotra]

+1
Chetan Mehrotra


On Tue, Nov 28, 2017 at 2:39 PM, Karl Pauls <karlpa...@gmail.com> wrote:
> +1
>
> regards,
>
> Karl
>
> On Monday, November 27, 2017, Stefan Seifert <sseif...@pro-vision.de> wrote:
>
>> +1
>>
>>
>
> --
> Karl Pauls
> karlpa...@gmail.com

[jira] [Commented] (SLING-6702) Make MetricsService accessible as easily as a Logger

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

 [ 
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 (JIRA)]

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)

Re: [VOTE] Release Apache Sling Commons Log 5.1.0

[Chetan Mehrotra]

> I see there's an open issue marked as a blocker
>  https://issues.apache.org/jira/browse/SLING-7157

That issue is fixed for Commons Log but there are other components
which still need to be fixed and hence the issue is open.
Chetan Mehrotra


On Mon, Nov 27, 2017 at 1:45 PM, Robert Munteanu <romb...@apache.org> wrote:
> Hi Chetan,
>
> On Mon, 2017-11-27 at 13:12 +0530, Chetan Mehrotra wrote:
>> We solved 9 issue in this release:
>> https://issues.apache.org/jira/projects/SLING/versions/12340651
>
> I see there's an open issue marked as a blocker
>
>   https://issues.apache.org/jira/browse/SLING-7157
>
> Should we fix it for this release?
>
> Robert

[jira] [Comment Edited] (SLING-7045) OSGi services should be managed by DS

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

 [ 
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)

[VOTE] Release Apache Sling Commons Log 5.1.0

[Chetan Mehrotra]

Hi,

We solved 9 issue in this release:
https://issues.apache.org/jira/projects/SLING/versions/12340651

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1820

You can use this UNIX script to download the release and verify the
signatures:
https://raw.githubusercontent.com/apache/sling-ide-tooling/master/check_staged_release.sh

Usage:
sh check_staged_release.sh 1820 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

regards
Chetan

[jira] [Resolved] (SLING-6044) Conflicting LogManager and LogWriter if using the same logfile

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[VOTE] Release Apache Sling Metrics RRD4J 1.0.2

[Chetan Mehrotra]

Hi,

We solved 2 issue in this release:
https://issues.apache.org/jira/projects/SLING/versions/12341592

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1818

You can use this UNIX script to download the release and verify the
signatures:
https://raw.githubusercontent.com/apache/sling-ide-tooling/master/check_staged_release.sh

Usage:
sh check_staged_release.sh 1818 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

regards
Chetan

[jira] [Commented] (SLING-7045) OSGi services should be managed by DS

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

 [ 
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)

[VOTE] Release Apache Sling JCR Registration 1.0.4

[Chetan Mehrotra]

Hi,

We solved 2 issue in this release:
https://issues.apache.org/jira/projects/SLING/versions/12328687

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1817

You can use this UNIX script to download the release and verify the
signatures:
https://raw.githubusercontent.com/apache/sling-ide-tooling/master/check_staged_release.sh

Usage:
sh check_staged_release.sh 1817 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

regards
Chetan

[jira] [Updated] (SLING-7157) metatype.properties file must not be in OSGI-INF/metatype

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (JIRA)]

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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

 [ 
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 (JIRA)]

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

[Chetan Mehrotra (JIRA)]

 [ 
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 (JIRA)]

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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

Etiquettes while merging PR from contributors

[Chetan Mehrotra]

Hi Team,

Given the switch to git I am now bit in dilemma on how to handle the
PR merge. With svn it was always done by applying the patch and
committing it. Keeps history fine. With Git there is choice to 'merge'
or rebase.

For external contributors it would be good if commit retains the
original author info. So I was thinking to follow approach mentioned
in [1]. In brief use

- `git merge --no-ff feature` for feature branches involving multiple commits
- `git cherry-pick feature` for simple bug fixes

Used this for SLING-7223. Note that while closing the PR gitbot adds
whole PR diff as comment to the jira

So far I liked the way history looked for any module in svn so bit
more comfortable with any approach which is closer to that

Any guidance here on approach to be taken would be helpful.

Chetan Mehrotra
PS: Do not want to initiate a never ending discussion around rebase or
merge! Just checking what approach we take for our project in general

[1] https://mislav.net/2013/02/merge-vs-rebase/

[jira] [Resolved] (SLING-7223) Spikes in RRD after restart

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

 [ 
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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[jira] [Commented] (SLING-3049) Make Logback Stacktrace Packaging data support OSGi aware

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Chetan Mehrotra (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-7223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)