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