-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support scanning a directory for log4j2 configuration files #2852
Comments
That is a very interesting idea Matt, thanks for bringing it to our
attention. 💯 Do you have a particular use case that you want to solve with
this mechanism?
|
@vy the use case is to enable a runtime to use a fixed configuration value and then allow for various deployments use cases to modify 0..n number of log4j2 configuration files without having to change the runtime's configured value for log4j2.configurationFile. Use Case 1: Log config per-environment
Use Case 2: Dynamic multi-tenant application
|
Hi @mattrpav, Your proposal certainly addresses several limitations in the way Log4j Core determines the appropriate configuration file, although I am not certain how these limitations should be addressed. From a maintainer perspective I would prefer not to have too many configuration knobs that I need to care about. If some feature applies to a very small number of environments, I would prefer to externalize it. Let's analyze the current situation and how we can improve it. Current statusCurrently Log4j Core has already a mechanism that looks for files named Admittedly this mechanism is limited:
Possible solutionsResolution of relative filenamesAs explained above, the search path for Log4j Core configuration files differs, depending on the value of
We should probably:
Note: We don't necessarily need a new configuration property. We could extend the definition of The default value of Determination of
|
@ppkarwasz 'log4j2.configurationDirectory' configuration property that supports comma separated sounds great! Note: This is not for Spring Boot, but approach would be the similar-- initial log4j2 context that is then programmatically reconfigured. |
I actually prefer Piotr's suggestion of using a trailing '/' to indicate it is a directory. |
I'm coming up to speed on log4j2 internals, so this is may be a rough riff-- re: ContextNameSelector -- perhaps a package prefix selector? Multi-tenant app could deploy:
Then:
..could resolve to the 'com.company.order' package prefix This has the added benefit of being able to fallback to a simple default context (log4j2.xml) on the desktop during development and unit testing. Classloader approach is a nice option, but can be incomplete since high-density apps may share a classloader to support shared JSON/XML model class marshallers. Perhaps a configuration to name the context selector class? |
There is already
While you can create a Ideally you don't only want to split the loggers of the classes in the Note: In practice separating the loggers of common libraries of a runtime environment is almost impossible. A more practical approach is to add some context data (see |
@mattrpav, are you referring to OS containers (Docker, Podman, etc.) or Java servlet containers? (I have the impression that you're referring to the former, while @ppkarwasz is talking about the latter. Hence, I feel like we are not on the same page.)
@ppkarwasz, I liked this approach. I had two other alternatives in mind:
|
What specifically does not seem to align to you?
A reasonable set of default filename globs should suffice without having to draw on a JDK 22 feature (keep in mind the next LTS after JDK 21 is JDK 25) -- log4j2*.json, log4j2*.yaml, log4j2*.xml, log4j2*.properties, etc.
If the default behavior is defined to scan sub-directories, this should not be needed. Defaults:
|
@mattrpav, what do you mean by a Java-based container? A Docker container?
Op ma 26 aug 2024 om 15:40 schreef Matt Pavlovich ***@***.***>
… Build a Java-based container ...
@mattrpav <https://github.com/mattrpav>, are you referring to OS
containers (Docker, Podman, etc.) or Java servlet containers? (I have the
impression that you're referring to the former, while @ppkarwasz
<https://github.com/ppkarwasz> is talking about the latter. Hence, I feel
like we are not on the same page.)
What specifically does not seem to align to you?
I had two other alternatives in mind:
1. **Support wildcards:** e.g., `-Dlog4j2.configurationFile=/opt/app/conf/log.d/*` – This matches the way `-cp` JVM option works and the [JEP 458: Launch Multi-File Source-Code Programs](https://openjdk.org/jeps/458) features freshly delivered in Java 22.
A reasonable set of default filename globs should suffice without having
to draw on a JDK 22 feature -- log4j2*.json, log4j2*.yaml, log4j2*.xml,
log4j2*.properties, etc.
2. **Support glob patterns:** e.g., `log4j2.configurationFile=/opt/app/conf/log.d/**/*` – This would be pretty powerful, but requires an in-house glob implementation, which sort of renders this option an overkill.
If the default behavior is defined to scan sub-directories, this should
not be needed.
Defaults:
1. Follow symlinks
2. Scan sub-directories
3. Limit sub-directory depth to a reasonably high value (ie. 16 or
32). This will provide flexibility, be performant, and provide an escape
hatch for problematic scenarios (symlink loops, etc)
—
Reply to this email directly, view it on GitHub
<#2852 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAARTSOCHCR7MENZ4VRS7KLZTMV5NAVCNFSM6AAAAABMVTSIHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJQGI2DKNJXGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@mattrpav, what purpose would the recursion serve? What happens if more than one |
Allows developers/devops to deploy Kubernetes config maps (one file per-subdirectory) without using a special type of volume (aka projected volume). Standard one ConfigMap per-subdirectory
Projected volume would allow:
|
@mattrpav, thanks for clarifying that you were referring to OS containers – as I indicated earlier, @ppkarwasz thought you were referring to Servlet containers. I am still keen on supporting configuration directories you proposed, but to better understand what is falling short in the current knobs: You can attach your Log4j configuration files in whichever way you want (bundle them in JARs, mount them using ConfigMaps, regular/projected volumes, etc.) and use the |
Note also that the
|
New property log4j2.configurationDirectory would work similar to the comma separated list in log4j2.configurationFile where multiple configuration files can be used for an application.
This behavior would allow dynamic loading of configuration files, instead of requiring the name of each configuration file ahead of time, which is the case with log4j2.configurationFile.
The text was updated successfully, but these errors were encountered: