[
https://issues.apache.org/jira/browse/FELIX-6407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17346424#comment-17346424
]
Tom Watson commented on FELIX-6407:
-----------------------------------
The original PR introduced an OSGi-SCR-incompatible extension that simply
changed the specified logger names that SCR should be using. This allows for
the root LoggerContext to be used to configure the log levels instead of having
to get the LoggerContext of every bundle to configure the various log levels
for all the SCR components.
I still do not understand why we would want the log events to look like they
are coming from SCR itself here nor why doing so helps with optimizations.
IIRC we have a single BundleListener that only listens for STOPPED events and
that does a simple removal from a map for the bundle's logger. I am surprised
this BundleListener is showing up as a performance hit for any scenario. You
mention that the bundle listener is trying to retrieve the log levels of every
bundle. Which bundle listener are you referring to? The one that LogManager
provides does nothing with log levels, it only removes something from a map on
the STOPPED event and I think there should only be one of these. Are you
referring to the BundleListener SCR uses in general to start processing bundle
components? Again, I am surprised that the usage of the OSGi Logger here is
showing up as a performance hit when the default log level of WARN is being
used. By and large there should be relatively few log events fired that are
WARN or ERROR and the Logger implementation must be highly optimized to be a
no-op when the log level is not met for a specific call to log.
> 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)
