[BUG] flytekit-java tries to discover slf4j implementation through parent class loader

[honnix]

Describe the bug

slf4j uses class loader to discover its implementations at runtime. ChildFirstClassLoader in flytekit-java first discovers implementations locally and then delegate to its parent class loader. While this makes sense for many scenarios, it does not work for slf4j because mixing an implementation and API from different class loaders will certainly cause class loading problem. While in practice this does not necessarily cause problem because slf4j will choose the first discovered one that is from the child, if there is, but if there does not exist one in child, a class loading problem will occur.

Expected behavior

ChildFirstClassLoader does not try to discover slf4j implementations in its parent class loader.

Additional context to reproduce

jflyte uses slf4j-simple as the implementation, so creating a task module using another implementation will result in slf4j warning about multiple implementations. If the task module has slf4j-api bundled but no implementation, a class loading problem will occur when trying to assign an instance loaded by parent class loader to a class loaded by the child.

Screenshots

No response

Are you sure this issue hasn't been raised already?

• Yes

Have you read the Code of Conduct?

• Yes

[honnix]

Closed by flyteorg/flytekit-java#145