[
https://issues.apache.org/jira/browse/FELIX-6407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17346931#comment-17346931
]
Tom Watson commented on FELIX-6407:
-----------------------------------
OK, I think I've finally located my cause of confusion. While testing this out
in my own context I had come across this unit test and behavior that I didn't
think it was correct in its checking for which bundle was logging the message.
I then looked at the code and the variable usages was all very confusing. So I
"fixed" that in this commit:
https://github.com/apache/felix-dev/commit/3fcd7df2ef84941f5abdd51808c2bb5cddf4184c#
One method was using `this.bundle` and the other was just using `bundle` but
its method had an input var of `m_bundle`. So I assumed it HAD to be wrong and
not the intention of the original code. So I am now convinced that WAS the
original intention of the code, but the var names were just confused.
> SCR Log Extension still logs using the log level of the extended bundle
> -----------------------------------------------------------------------
>
> Key: FELIX-6407
> URL: https://issues.apache.org/jira/browse/FELIX-6407
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Affects Versions: scr-2.1.24, scr-2.1.26
> Reporter: Amit Mondal
> Priority: Minor
> Labels: pull-request-available
>
> The SCR incorporates 3 different types of logging:
> * Logging for SCR main code (_*ScrLogger*_)
> * Logging on behalf of the bundle comprising the SCR component
> (_*BundleLogger*_)
> * Logging on behalf of the component under processing (_*ComponentLogger*_)
> According to the current implementation, the SCR logging is by default
> enabled and it logs using the log levels of the bundles comprising the SCR
> components.
> This [PR|https://github.com/apache/felix-dev/pull/36] by [~pkriens] has been
> merged to introduce a non-OSGi standard extension which enables consumers to
> extend the SCR logging functionality, that is, a consumer can on demand set
> the log level of the SCR bundle itself which after setting a specific
> property (_*ds.log.extension*_) will be enabled. Now, SCR will be able to use
> the log level of itself for all the logging. It won't use the log levels of
> the bundles under processing.
> The specified SCR versions still log using the log levels of the bundles
> under processing even though _*ds.log.extension*_ framework property is
> correctly set.
> This feature to extend SCR logging is useful in very low memory IoT devices
> where many bundles (>200) are installed and SCR's intensive logging becomes
> very costly.
> The feature can further be extended to disable the logging completely. Hence,
> I am proposing the following approach:
> We should introduce another framework property to disable the SCR logging
> completely, let's say _*ds.log.enabled*_
> By default, this property will not be set which means the logging is enabled
> by default, otherwise consumer can decide to disable the logging by setting
> it to _*false*_
> If the logging is still enabled, the consumer now has two options:
> * Use the log level of the extended bundle (bundle under processing)
> * Use the log level of the SCR bundle itself
> If we decide to let SCR use its own log level, the _*ds.log.extension*_ needs
> to be set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
