log4j2.script.enableLanguages or log4j2.scriptEnableLanguages?

[martin-dorey-hv]

Description

Yeah, it doesn't functionally matter. I know. Now.

If the rule is to follow camelCaseNames, then shouldn't new source set a good example?

Configuration

2.24.0

Logs

Reproduction

https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.scriptEnableLanguages says it's log4j2.scriptEnableLanguages.

We're told earlier, by https://logging.apache.org/log4j/2.x/manual/systemproperties.html that:

Since Log4j 2.10 all the property names follow a common naming scheme:
log4j2.camelCasePropertyName

So scriptEnableLanguages then - simple, clear, good. It does go on to say:

To provide backward compatibility with versions older than 2.10 a certain number of additional property names is also supported using a fuzzy matching algorithm.

(There's a plural agreement problem there - "is" should be "are".)

However, the notes for a release later than 2.10, https://logging.apache.org/log4j/2.x/release-notes.html#release-notes-2-17-2, say:

Require log4j2.Script.enableLanguages to be specified to enable scripting for specific languages. (LOG4J2-2486)

... and that different name is indeed the only name to be found in the source, at least the parts that aren't documentation, at https://github.com/search?q=repo%3Aapache%2Flogging-log4j2+enableLanguages&type=code.

It wasn't until I found
https://github.com/apache/logging-log4j2/blob/2.x/log4j-api/src/main/java/org/apache/logging/log4j/util/PropertySource.java#L135 that I became convinced that this wasn't the cause of my problems.

Tidying up old source code, that's somewhat risky and no fun, but shouldn't new code follow the new rules?

[ppkarwasz]

Hi @martin-dorey-hv,

Thanks for the report. I normalize property names in the release notes in #3089 .

Regarding the source code, we keep the old names for compatibility sake. If a user uses the same property name as in the source code, it will work. However, since 2.24.0 the token-based matching will not work (see #2849).

The non-normalized property names are intentionally omitted in the new documentation: Log4j Core 3.x will change the property names again to allow for properties that apply to a single logger context, but will provide a compatibility mechanism for normalized properties. This will allow for a gradual migration by:

• Upgrading the property names to their 2.10 normal form first,
• Upgrading the property names to their 3.0.0 normal form later.

[martin-dorey-hv]

I'm glad I clicked on those links - I thought I had understood... but not as well as I did after. Thanks for quietly sorting the is/are thing and normalizing one of the mentions of log4j2.Script.enableLanguages - in the release notes - that had led to my confusion.
I'm surprised you could retroactively edit the latter but it's great that you can. Being able to find all the names that have previously been advertised, to preserve compatibility, yeah, I can see that would be a good reason to leave the old names in the source.

Log4j Core 3.x will change the property names again

I wish you the best of luck in herding the cats, so they stick to the rules, this time.

[ppkarwasz]

Being able to find all the names that have previously been advertised, to preserve compatibility, yeah, I can see that would be a good reason to leave the old names in the source.

If you can think of a way to have also the new names in the source (so you can search for the string), we are open to contributions.

In 3.x we use a JSON file (with a fixed name) that gives as a mapping between the new names and a list of old names. This mechanism however breaks if people shade multiple Log4j artifacts.