You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is inconvenient for developing modules depending on libraries using slf4j. Technology-Aws depending on AWS SDK is the example.
We can not temporalily use another binding like slf4j-simple if MonitorProvider is in the classpath. Since the MonitorProvider is provided by org.eclipse.edc:boot, most of the code depending on EDC could be affected.
S3DataPlaneIntegrationTest STANDARD_ERROR
SLF4J: Class path contains multiple SLF4J providers.
SLF4J: Found provider [org.eclipse.edc.boot.monitor.MonitorProvider@47c64cfe]
SLF4J: Found provider [org.slf4j.simple.SimpleServiceProvider@6ce90bc5]
SLF4J: See https://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual provider is of type [org.eclipse.edc.boot.monitor.MonitorProvider@47c64cfe]
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
Making the feature opt-in could be an option. If the feature is enabled by loading the extension, EDC Config is available on initialize. Modules not loading BaseRuntime (e.g. Technology-AWS) can use alternative slf4j binding during development.
The text was updated successfully, but these errors were encountered:
AFAIR the MonitorProvider was added a long time ago to satisfy some transitive dependency. Do we even need it anymore or can we remove it?
That would mean that people can just register their downstream implementation of a Monitor, e.g. an Slf4jMonitor.
I submitted #3463 which removes the MonitorProvider from the code path of BaseRuntime. The SLF4J-Monitor bridge feature still could be useful for users of existing monitor like LoggerMonitorExtension to make log destination settings simple.
Feature Request
Which Areas Would Be Affected?
boot, monitor
Why Is the Feature Desired?
We can not get log of underlying libraries using slf4j if the log level is equal to or smaller than INFO since the log level of slf4j logger is hard coded.
It is inconvenient for developing modules depending on libraries using slf4j. Technology-Aws depending on AWS SDK is the example.
We can not temporalily use another binding like slf4j-simple if MonitorProvider is in the classpath. Since the MonitorProvider is provided by org.eclipse.edc:boot, most of the code depending on EDC could be affected.
Solution Proposal
Making the log level of slf4j logger configurable as done for slf4j-simple.
Making the feature opt-in could be an option. If the feature is enabled by loading the extension, EDC Config is available on
initialize
. Modules not loading BaseRuntime (e.g. Technology-AWS) can use alternative slf4j binding during development.The text was updated successfully, but these errors were encountered: