-
Bug
-
Resolution: Done
-
Major
-
1.9.5.Final
-
None
-
False
-
None
-
False
Unless there is a specific reason to use getClass().getClassLoader() as the default class loader, Thread.currentThread().getContextClassLoader() would be a safer default from the integration perspective with environments that define their own classloading policies.
The original issue was reported in Quarkus quarkusio/quarkus#27565. When a project contains a custom converter implementation, the CommonConnectorConfig in the Debezium core (which is an external project dependency) loading converter classes may fail with a class loading exception. What happens in in this case is Quarkus loads the local project dependencies in a classloader that is higher in the hierarchy than the classloader loading the core Debezium classes, making the CommonConnectorConfig to look for converter implementations among the core Debezium classes and the system classloader, which may lead to a failure.
- is related to
-
DBZ-6075 Loading Custom offset storage fails with Class not found error
- Closed