Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
scr-2.1.24, scr-2.1.26
Description
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 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.
Attachments
Issue Links
- links to
