Validate scripts in global `<Scripts>` container

[ppkarwasz]

The ScriptsPlugin should perform a validation of the script nested configuration elements and:

• Remove the scripts that do not have a name.
• Issue a status logger warning, when this condition occurs.

[JWT007]

Hi @ppkarwasz,

So I was going to fix this but in testing realized that no script is every really created with no name.

The super-constructor for Script/ScriptRef/ScriptFile when passed a null name evaluates a default from toString().

public AbstractScript(final String name, final String language, final String scriptText) {
    this.language = language;
    this.scriptText = scriptText;
    this.name = name == null ? this.toString() : name;
}

Example: org.apache.logging.log4j.core.script.Script@7857fe2.

So by the time the array of scripts shows up in the ScriptsPlugin there are no scripts without names.

It is however a name that probably could never be sensibly referenced.

[JWT007]

@ppkarwasz what should be done with this ticket? see last comment.

Of course, the Script builders and AbstractScript constructor can be modified...

[ppkarwasz]

@ppkarwasz what should be done with this ticket? see last comment.

Of course, the Script builders and AbstractScript constructor can be modified...

Since AbstractScript.getName() is used extensively accross the code, I believe that we need an additional property (getConfiguredName()?) to allow the ScriptsPlugin to remove the scripts without an explicit name.

[jhl221123]

@ppkarwasz,

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?

[ppkarwasz]

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 Script resolution depends on order of element in config file #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().

[injae-kim]

Fix PR: #3691