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 therefore not possible for us to exclude either logging API in our build. This can be confusing to downstream users, particularly when they see log4j usage in our codebase, but on command line are always greeted with this lovely prefix:
SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.
What solution would you like?
Downstream users of SDK should be aware of this constraint so that they can configure their logging appropriately. The developer guide should mention the above constraint and appropriate workarounds.
What alternatives have you considered?
Removing hard dependency on log4j2 API in OpenSearch. I'll probably propose that but it's not backwards compatible so it'll be a 3.x feature. At some point I'll audit the codebase to see if there are any others.
Is your feature request related to a problem?
SDK has transitive dependencies on multiple logging APIs:
Settings
class (at least) requires a Log4J classIt is therefore not possible for us to exclude either logging API in our build. This can be confusing to downstream users, particularly when they see log4j usage in our codebase, but on command line are always greeted with this lovely prefix:
What solution would you like?
Downstream users of SDK should be aware of this constraint so that they can configure their logging appropriately. The developer guide should mention the above constraint and appropriate workarounds.
What alternatives have you considered?
Removing hard dependency on log4j2 API in OpenSearch. I'll probably propose that but it's not backwards compatible so it'll be a 3.x feature. At some point I'll audit the codebase to see if there are any others.
Do you have any additional context?
Relates to #824
The text was updated successfully, but these errors were encountered: