Remove jvmrunargs lookup

[ramanathan1504]

jvmrunargs was added in 2014-08-20 (1f64e68), and never worked until it got accidentally fixed in 2.25.0 (see #3071 and f7c26cd), which was released in 2025-06-13. We decided to remove it¹.

¹ Link to the internal Slack conversation. (Only accessible by certain ASF committers and some limited set of guests.)

[ppkarwasz]

Hi @ramanathan1504,

Thanks for the PR! 💯

From what I can tell, the jvmrunargs lookup was already fixed in version 2.25.0, so the main code changes here may not be needed. However, the unit tests you’ve added are very valuable. They’ll help ensure the lookup keeps working. The absence of such tests is likely why a feature that never fully worked managed to ship in so many releases.

Could you:

• Remove the main code changes but keep JvmRunArgsLookupTest.
• Consider adding documentation for jvmrunargs (either in this PR or in a follow-up). See #3876 for details.

[github-actions]

Job	Requested goals	Build Tool Version	Build Outcome	Build Scan®
build-macos-latest	clean install	3.9.8	❌
build-ubuntu-latest	clean install	3.9.8	❌
build-windows-latest	clean install	3.9.8	❌

Generated by gradle/develocity-actions

[vy]

@ramanathan1504, would you mind implementing the following changes, please?

1. Remove log4j2-test.xml that you added
2. Remove o.a.l.l.core.lookup.Interpolator::LOOKUP_KEY_JVMRUNARGS field
3. Remove o.a.l.l.core.lookup.JmxRuntimeInputArgumentsLookup
4. Move the changelog entry file to src/changelog/.2.x.x/3874_remove_jvmrunargs_lookup.xml
5. Fix the changelog entry file syntax (see 3176_validate_scripts_in_ScriptsPlugin.xml for an example)
6. Set the entry.type to removed in the changelog entry file

[ramanathan1504]

Fixes #3874

• Removed log4j2-test.xml
• Removed LOOKUP_KEY_JVMRUNARGS field from Interpolator
• Removed JmxRuntimeInputArgumentsLookup class
• Moved and updated the changelog entry to src/changelog/.2.x.x/3874_remove_jvmrunargs_lookup.xml with the correct format and type

Please review and let me know if any further changes are needed.

[vy]

@ramanathan1504, could you remove JmxRuntimeInputArgumentsLookup, please? (Please review the Files changed tab in GitHub after pushing your changes.)

[ramanathan1504]

Understood, I’ll remove it. I’ll be more careful in future PRs to ensure such issues don’t occur again.

[vy]

@ramanathan1504, you need to sign your commits. The "In a GitHub PR, how can I sign (not sign-off!) existing commits?" prompt creates a good enough ChatGPT response.

Note that since you'll be truncating the history anyway, you can as well squash all your changes into a single commit, sign it, and force-push it.

I’ll be more careful in future PRs to ensure such issues don’t occur again.

No worries. Shit happens.

[ppkarwasz]

Hi @ramanathan1504,

Thanks for the contribution!

Removing a class is technically a breaking change, which is why the BND Baseline check fails.

However, since we’ve decided this particular removal should not be treated as a breaking change, you’ll need to override the check by doing the following:

1. Identify the element that contains the removed class. For classes, this means the containing package:
   

   logging-log4j2/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/package-info.java

   Lines 23 to 28 in 2f79c39

   	@Export
   	@Version("2.24.1")
   	package org.apache.logging.log4j.core.lookup;
   	import org.osgi.annotation.bundle.Export;
   	import org.osgi.annotation.versioning.Version;

2. Add a @BaselineIgnore("2.26.0") annotation to that package. This tells BND to ignore the semver violation up to version 2.26.0 of log4j-core.

3. Even though we’re not treating this as a MAJOR change, it is a MINOR change for the package. Per OSGi semantic versioning, you must bump the package version (2.24.1) by at least one minor version.
   Our convention is to align the package version with the library version, so update it to @Version("2.26.0"). This way, the package version clearly answers the question: “In which Log4j version did the last API change in this package occur?”

After these annotation changes, please run the build to identify and remove the tests that rely on the removed lookup.

[ramanathan1504]

Hi @ppkarwasz,

Thanks for the detailed instructions! I’ll make the changes as suggested:
• Add @BaselineIgnore("2.26.0") to the package.
• Bump the package version to @Version("2.26.0").
• Update/remove tests that rely on the removed class.

I’ll push the updates shortly.