[
https://issues.apache.org/jira/browse/FELIX-6407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17346609#comment-17346609
]
Amit Mondal commented on FELIX-6407:
------------------------------------
Thanks, Tom, for your quick response. The original PR introduced both the
functionalities to assign respective logger names and the functionality to have
SCR its own log level to log messages. The second functionality, that's why
used the SCR bundle instance to retrieve the log level that has been assigned
to the SCR bundle.
For example:
{code:java}
"org.osgi.service.log.admin|org.apache.felix.scr" : {
"ROOT": "INFO"
}
{code}
I was actually referring to
{code:java}
org.apache.felix.scr.impl.logger.LogManager.Lock.getLogger(LoggerFacade,
Bundle, String){code}
that is called for every bundle using SCR. According to the current
functionality, even if we configure the *_ds.log.extension_* to use the
non-spec-compatible extended logging, the log level is retrieved for every
bundle comprising SCR components which was not intended initially.
The intention was not to use or track the log level of any other bundle if the
user decides to use extended logging (when *_ds.log.extension_* is set to
*_true_*) as in this scenario, SCR should only use its own log level.
If we do not use SCR's bundle instance, the existing functionality will
retrieve the log level of every bundle that uses SCR. That's why Peter
introduced *_ds.log.extension_* which was also intended to use the
aforementioned log level of the SCR bundle to log the internal messages. This
ensured that we don't have to retrieve the log levels of every bundle using SCR
components.
> 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)
