Custom Classloaders

[Alan Bateman]

On 26/01/2024 10:46, Robert Scholte wrote:
>
> Hi,
>
> I’m working on a new application, using jlink to build it.
>
> One challenge is related to the simplelogger of SLF4J (as SLF4J-api is 
> probably the most used logging api, the simplelogger implementation 
> matches my requirements)
>
> There are 2 things that I would like to adjust:
>
>  1. Simplelogger uses the classloader to find the
>     simplelogger.properties (
>     https://github.com/qos-ch/slf4j/blob/master/slf4j-simple/src/main/java/org/slf4j/simple/SimpleLoggerConfiguration.java#L107-L130
>     ).
>
> However, I want to externalize this file to 
> ${java.home}/conf/simplelogger.properties, so users can adjust it to 
> their preferences. If I could change the classloader I could control 
> where to find this file.
>
> When bundling simplelogger with jlink the jar will end up in the 
> AppClassloader due to the SimpleServiceProvider.
>
> The only option to avoid this, is to move this jar to a separate 
> directory and when making a new ModuleLayer, and use ModuleFinder with 
> this path.
>
> But still, I see no way to change the classloader for this jar.
>
>  2. The simplelogger.properties is the default configuration, and I
>     want to make it possible to override these values.
>
> The simplelogger offers the option to use SystemProperties to override 
> values from simplelogger.properties.
>
> I want to avoid that the System.properties will be polluted with 
> entities just for logging.
>
> As far as I know it is not possible to scope System.properties: they 
> are global, available for every part of the application.
>
> Another idea I had was to extend the simplelogging.properties 
> resources at runtime using the SequenceInputStream, and for this I 
> also need to have control over the classloader, as it requires to 
> override the ClassLoader.getResourceAsStream()
>
> It seems both challenges could be solved if could control the 
> classloader (while still being protected by jdk.internal.loader.Loader).
>
> Am I missing some feature or it there another way to solve these issues?
>
>
Hi Robert,

The code you linked to using the current Thread's context ClassLoader 
(CCL) to find the resource. So not the same thing as the class loader 
that defined SimpleLoggerConfiguration. At a guess, that code look like 
it is intended to support bundling of logging configuration with an 
application. It means code can set the current Thread's CCL, initialize 
SL4J to so it find the resource (config file) with that class loader, 
and reset it after.

To be editable in ${java.home}/conf would require 
changing SimpleLoggerConfiguration.loadProperties to look for the 
properties file there. The defining classer for 
SimpleLoggerConfiguration won't change that as Class.getResource or 
ClassLoader.getResource doesn't find resources there.

-Alan




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20240126/24e4329b/attachment-0001.htm>