ppkarwasz commented on issue #3176:
URL:
https://github.com/apache/logging-log4j2/issues/3176#issuecomment-2908062977
> If adding `configuredName` to `AbstractScript` and filtering in
`ScriptsPlugin` is still the plan, I'd like to work on it. Is this up for grabs?
Hi @jhl221123,
Thanks for offering to take this on — I’ve assigned the issue to you.
There’s no finalized solution yet, so you have flexibility in how you want
to approach it. Since this issue is part of a broader problem involving script
referencing in configuration files, I’ve outlined the overall context and a
couple of potential solution paths below. These are just suggestions to help
guide your thinking — feel free to build on them or propose your own approach.
## Problem Statement
We aim to ensure consistent and reliable handling of script references
within configuration files. This involves two related sub-problems:
* **Part 1 (this issue):**
Enforce that all children of the global `<Scripts>` container define a
user-visible `name`, enabling them to be referenced from other parts of the
configuration.
* **Part 2 (issue #3336):**
Postpone the validation of `<ScriptRef>` elements until all configuration
elements—including those within `<Scripts>`—have been instantiated. Early
validation may result in resolution errors if a `<ScriptRef>` appears before
the corresponding script definition in the file.
## Part 1 – Script Name Handling
### Current Behavior
At present, `AbstractScript.getName()` is guaranteed to return a non-`null`
value, but the logic behind this value varies depending on the script type:
1. **Explicit name**: If the user specifies a `name` attribute in the
configuration file, that value is used.
2. **Implicit name (for `<ScriptFile>`)**: If no `name` is provided, the
script's `path` attribute is used as a fallback. While this provides a usable
identifier, this behavior is **undocumented** and therefore non-obvious to
users.
3. **Fallback value (for `<Script>`)**: If no `name` is specified,
`Object.toString()` is used to derive a name. This fallback produces a value
that is neither predictable nor referenceable by users.
In practice, this means that `<Script>` elements without an explicit `name`
are effectively unusable as references in the configuration file. To improve
usability and predictability:
* A warning should be emitted when a `<Script>` inside the global
`<Scripts>` container lacks a `name`.
* No warning should be shown when the `<Script>` is embedded in another
Log4j plugin, where referencing by name is not required.
The ideal solution would be to change `getName()` so that it only returns
values explicitly assigned by the user, and `null` otherwise. However, this
change is non-trivial because most script-consuming plugins currently call
`ScriptManager.getScript(script.getName())`. This requires a rethinking of how
scripts are registered and retrieved.
## Proposed Solutions
### **Solution 1 – Add an Internal Identifier**
Introduce a distinct concept of an internal script ID, separate from the
user-assigned name:
1. Add a new method `getId()` to `AbstractScript`. This method returns:
* The result of `getName()` if non-`null`, or
* A fallback value such as `Integer.toString(hashCode())` if no name is
provided.
2. Update all usages of `ScriptManager.getScript(script.getName())` to
instead use `script.getId()`, ensuring backward compatibility.
3. During the creation of top-level scripts in
`ScriptsPlugin.createScripts`, add validation to ensure that all scripts have
an explicit `name`. If any are missing, throw a `ConfigurationException`.
### **Solution 2 – Assign identifiers in `ScriptManager`**
Shift script registration to a more robust and explicit mechanism:
1. Introduce a new method `ScriptManager.registerScript(AbstractScript
script)` that returns a generated identifier (typically a `String`).
2. This identifier can then be used in subsequent `getScript()` calls.
3. Replace the current `ScriptManager.addScript()` mechanism with
`registerScript()`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
