Uniform handling of location and URIs

[ppkarwasz]

Many Log4j components use URI-sh configuration attributes:

• configuration factories allow a ConfigurationSource to be specified as URI, URL or file name,
• the MutableThreadContextMapFilter accepts an URI or file name to retrieve its configuration,
• JSON Template Layout accepts an URI to retrieve its configuration.

Each of these configuration attributes is handled in a different way. For example:

• JTL only handles file: and classpath: URIs,
• the way URIs without a schema are interpreted differs.

We should introduce an abstraction similar to ResourceLoader that:

• supports at least the classpath, file, http and https protocols,
• is extensible to new protocol handlers,
• specifies how a relative URI without a protocol needs to be interpreted. This mechanism should be extensible: e.g. a standard implementation could interpret it as classpath or file resources. A log4j-web specific implementation could interpret it as war, classpath or file resource,
• has a coherent way to handle errors: file names and Java URLs don't always follow the URI syntax.

Remark: other Log4j components might also profit from this abstraction. For example the File appender could be easily adapted to use network filesystem URIs or at least it should be able to use NIO file systems.

[vy]

I wrote JTLs Uris class you mentioned before JTL became a part of the Log4j. Hence, I can totally relate to the absence of this resource loading mechanism and I fully support the idea of introducing such a mechanism. 💯