[
https://issues.apache.org/jira/browse/FELIX-6407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17346177#comment-17346177
]
Tom Watson commented on FELIX-6407:
-----------------------------------
My understanding of the original solution is that a new prefixes are used for
all the loggers:
* An ScrLogger will log with the name "org.apache.felix.scr.impl"
* A BundleLogger will log with the name "org.apache.felix.scr.<component bundle
symbolic name>"
* A ComponentLogger will log with the name "org.apache.felix.scr.<component
bundle symbolic name>.<component name>"
The idea was that the Logger will still be gotten using the component bundle
where appropriate except now we use these specific logger names such that
LoggerAdmin can be used to either enable logs for specific bundles or they can
enable logs on a global basis:
For example, if you want to disable logging altogether the the following
LoggerAdmin configuration would be done:
{quote}
LoggerAdmin loggerAdmin = getLoggerAdmin();
// use null name to get root logger context
LoggerContext loggerContext = loggerAdmin.getLoggerContext(null);
Map<String, LogLevel> logLevels = loggerContext.getLogLevels();
// disables all but audit for ScrLogger
logLevels.put("org.apache.felix.scr.impl", LogLevel.AUDIT);
// disables all but audit for BundleLogger and ComponentLogger
logLevels.put("org.apache.felix.scr", LogLevel.AUDIT);
loggerContext.setLogLevels(logLevels);
{quote}
You can then use the root logger context to enable debug for specific bundles
based on BSN:
{quote}
LoggerAdmin loggerAdmin = getLoggerAdmin();
// use null name to get root logger context
LoggerContext loggerContext = loggerAdmin.getLoggerContext(null);
Map<String, LogLevel> logLevels = loggerContext.getLogLevels();
// enable debug for org.apache.felix.configadmin for BundleLogger and
ComponentLogger
logLevels.put("org.apache.felix.scr.org.apache.felix.configadmin",
LogLevel.DEBUG);
// enable trace for org.tjwatson bundle component names my.component
logLevels.put("org.apache.felix.scr.org.tjwatson.my.component", LogLevel.TRACE);
loggerContext.setLogLevels(logLevels);
{quote}
I don't see the need to always use SCR's bundle object to obtain the individual
component bundle loggers when the root LoggerContext can be used to set the log
levels in the way that I think you are needing. I also question the necessity
of the disable all logs option when you can crank the logger level down to
AUDIT for all using the root logger context. SCR currently never logs anything
with AUDIT level so this effectively disables all logs.
> 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)
