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
The values in the PatternLayoutBase defaultConverterMap and instanceConverterMap are class names. The ch.qos.logback.core.pattern.parser.Compiler class attempts to load the class for those class names with the assumption that those classes are visible to the classloader that loaded the logback-core classes.
Unfortunately, in an OSGi environment, my custom converter classes from a custom OSGi bundle are not visible to the classloader of the logback-core bundle. This scenario results in a "Failed to instantiate converter class" error and it doesn't work as expected.
My proposal is to allow the the values of the defaultConverterMap and instanceConverterMap to alternately be supplied as a Supplier function instead of a classname. The Supplier would not have the same class visibility problem.
Using a Supplier seems to be a technique that I see in other places in the logback codebase, so it seems like it should make sense to allow that for this scenario as well.
I will supply a PR with the proposed changes for your consideration
The text was updated successfully, but these errors were encountered:
The values in the PatternLayoutBase defaultConverterMap and instanceConverterMap are class names. The ch.qos.logback.core.pattern.parser.Compiler class attempts to load the class for those class names with the assumption that those classes are visible to the classloader that loaded the logback-core classes.
Unfortunately, in an OSGi environment, my custom converter classes from a custom OSGi bundle are not visible to the classloader of the logback-core bundle. This scenario results in a "Failed to instantiate converter class" error and it doesn't work as expected.
My proposal is to allow the the values of the defaultConverterMap and instanceConverterMap to alternately be supplied as a Supplier function instead of a classname. The Supplier would not have the same class visibility problem.
Using a Supplier seems to be a technique that I see in other places in the logback codebase, so it seems like it should make sense to allow that for this scenario as well.
I will supply a PR with the proposed changes for your consideration
The text was updated successfully, but these errors were encountered: