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¹. This fixes #2726.

¹ 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-ubuntu-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.

[ramanathan1504]

@ppkarwasz

Hi, I have applied the changes as you requested. The BND baseline check is now overridden.

I also had to fix an unrelated test failure in NamedInstantPatternTest that was causing the build to fail.

The full mvn clean install now passes successfully. This should be ready for another look. Thanks!

[ramanathan1504]

@ppkarwasz
Thanks for the clear guidance! You're right, I should have separated the concerns.
I have reverted the change to NamedInstantPatternTest.java and updated the PR. It now only contains the BND baseline changes as originally requested.
I've also opened a new issue for the test failure.
I'll be sure to keep future PRs focused on a single issue. Thanks again for the review!

[ramanathan1504]

Hi 👋,
I noticed the CI failures are coming from JeroMqAppenderTest (No appender named JeroMQAppender). Since my changes don’t touch this area, I assume it’s an unrelated infra/environment issue. Please let me know if you’d like me to help investigate further.

Thanks!

[ppkarwasz]

Hi,

You’re right, the JeroMqAppenderTest failure is completely unrelated to your changes.

It’s become a bit of a Moby Dick for me, so I guess I need to sharpen my harpoon. 😉

On a more serious note, the failure was caused by a port binding issue. Since the test binds the JeroMQ peer to port 0 (ephemeral), it suggests either:

• a bug in JeroMQ, or
• all ephemeral ports being in use (possible, though unlikely).

Here’s the relevant log output:

07:42:29.859 main DEBUG Building Plugin[name=appender, class=org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqAppender].
07:42:29.885 main DEBUG createAppender(name="JeroMQAppender", PatternLayout(%X{foo}%m), Filter=null, ={endpoint=tcp://*:0, endpoint=ipc://info-topic}, ignoreExceptions="false", affinity="0", backlog="100", delayAttachOnConnect="false", identity="null", ipv4Only="true", linger="-1", maxMsgSize="-1", rcvHwm="1000", receiveBufferSize="0", receiveTimeOut="0", reconnectIVL="100", reconnectIVLMax="0", sendBufferSize="0", sendTimeOut="0", sndHwm="1000", tcpKeepAlive="-1", tcpKeepAliveCount="-1", tcpKeepAliveIdle="-1", tcpKeepAliveInterval="-1", xpubVerbose="false")
07:42:29.886 main DEBUG Creating JeroMqAppender with name=JeroMQAppender, filter=null, layout=%X{foo}%m, ignoreExceptions=false, endpoints=[tcp://*:0, ipc://info-topic]
07:42:29.953 main DEBUG Starting JeroMqManager JeroMQAppender
07:42:30.163 main ERROR Unable to invoke factory method in class org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqAppender for element JeroMQ: org.zeromq.ZMQException: Errno 48 : Address already in use
java.lang.reflect.InvocationTargetException