Skip to content

Conversation

frankvicky
Copy link
Contributor

Please refer to #17373 (comment) for further details.
This PR does the following things:

  • Move deprecation warning to kafka-run-class
  • Remove unnecessary jacksonDatabindYaml dependency from modules
  • Add upgrade notes about log4j2.

Committer Checklist (excluded from commit message)

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation (including upgrade notes)

@github-actions github-actions bot added triage PRs from the community build Gradle build or GitHub Actions small Small PRs labels Dec 21, 2024
@chia7712
Copy link
Member

@frankvicky as @ijuma's comment in https://issues.apache.org/jira/browse/KAFKA-18247, please add the log4j2 transform ci to the upgrade note.

See <a href="https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=181308223">KIP-750</a> for more details
</li>
<li>
Logging framework has been migrated from Log4j to Log4j2.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we mention the behavior if you do not convert the configuration files? I believe there is a compatibility mode with some limitations?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Log4j provides a way to convert Log4j 1.x properties at runtime (Log4j Migration Guide).

To enable this feature, we can set both LOG4J_COMPATIBILITY=true and specify the configuration file using LOG4J_CONFIGURATION_FILE=file.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to automatically detect if log4j 1.x properties are used and, if so, automatically enable this mode? It seems like a huge problem if customers lose their logging while upgrading to 4.0+.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can always enable that compatibility feature as the bridge jar is already included now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even better if it can be always enabled with no significant downside.

@github-actions github-actions bot removed the triage PRs from the community label Dec 22, 2024
Copy link
Member

@chia7712 chia7712 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@frankvicky thanks for your patch

implementation project(':storage')
implementation project(':server-common')
implementation libs.slf4jApi
implementation libs.jacksonDatabindYaml
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is required as test-common needs to parse yaml in production code.

build.gradle Outdated
implementation project(':raft')
implementation project(':storage')
implementation project(':server-common')
implementation libs.slf4jApi
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please take a look at @ijuma's comment (#17373 (comment))

maybe we can create a variable to collect them and then add them to implementation for each module:

  log4jRuntimeLibs = [
    libs.log4j1Bridge2Api
    libs.jacksonDatabindYaml
  ]
  log4jLibs = [
    libs.slf4jApi
    libs.slf4jLog4j2
    libs.log4j2Api
    libs.log4j2Core
  ]
...
implementation log4jLibs
runtimeOnly log4jRuntimeLibs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have tried it on my local machine but it led to tons of failure of tests.
I would keep debugging on my local machine.

See <a href="https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=181308223">KIP-750</a> for more details
</li>
<li>
Logging framework has been migrated from Log4j to Log4j2.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Log4j provides a way to convert Log4j 1.x properties at runtime (Log4j Migration Guide).

To enable this feature, we can set both LOG4J_COMPATIBILITY=true and specify the configuration file using LOG4J_CONFIGURATION_FILE=file.

@frankvicky frankvicky force-pushed the log4j2-follow-up branch 2 times, most recently from c95cd3c to c69d421 Compare December 23, 2024 16:14
@github-actions github-actions bot removed the small Small PRs label Dec 23, 2024
build.gradle Outdated
implementation libs.slf4jApi
implementation libs.opentelemetryProto
implementation libs.protobuf
implementation log4jLibs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, clients and streams should not have any log dependency besides slf4j. The idea is that client modules shouldn't include logging implementations while server modules should. Client modules run alongside user applications and the logging library should be aligned with the application logging library.

Copy link
Member

@chia7712 chia7712 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@frankvicky could you please also remove log4j2CoreTest? it is unused.

# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
Configuration:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please open a jira for this change? tools-log4j.properties is still used in code base

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

implementation libs.junitPlatformLanucher
implementation libs.junitJupiterApi
implementation libs.junitJupiter
implementation log4jLibs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

line#1656 implementation libs.slf4jApi is unnecessary now.

@frankvicky frankvicky force-pushed the log4j2-follow-up branch 3 times, most recently from e6000ec to 5af4fb4 Compare December 24, 2024 11:09
LOG4J1_CONFIG=$(echo "$KAFKA_LOG4J_OPTS" | grep -o 'log4j\.configuration=\S*' | cut -d'=' -f2)

# Enable Log4j 1.x configuration compatibility mode for Log4j 2
export LOG4J_COMPATIBILITY=true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@frankvicky could you please test the compatibility on your local?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From document, set one of confituration from log4j1.compatibility and log4j.configuration if needing to install log4j1 to log4j2 bridge. It looks like we can set LOG4J_COMPATIBILITY=true only if LOG4J1_CONFIG has properties file. Also, setting LOG4J_CONFIGURATION_FILE="$LOG4J1_CONFIG" only if LOG4J1_CONFIG doesn't have properties file.

https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html#ConfigurationCompatibility

@frankvicky
Copy link
Contributor Author

Hi @chia7712
I have tested log4j compatibility on my local machine.

Explicit set KAFKA_LOG4J_OPTS:
Screenshot from 2024-12-29 14-51-13

Leave KAFKA_LOG4J_OPTS as null:
image

Copy link
Member

@FrankYang0529 FrankYang0529 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks for the patch. With log4j 1 properties, I can see log on console.

build.gradle Outdated
// ZooKeeper (potentially older and containing CVEs)
libs.nettyHandler,
libs.nettyTransportNativeEpoll,
libs.slf4jApi,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why we need this change?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spotbugsSlf4j - configuration for the SLF4J provider to run SpotBugs
\--- org.slf4j:slf4j-simple:2.0.0
     \--- org.slf4j:slf4j-api:2.0.0

spotbugs requires the 2.x slf4j, so forcing the version can cause log issue in running spotbugs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I previously encountered version inconsistency issues on my local machine. While those issues have been resolved, this change represents a modification that should have been removed but was accidentally missed during cleanup. 😬

@chia7712 chia7712 merged commit 585b7db into apache:trunk Dec 30, 2024
9 checks passed
chia7712 pushed a commit that referenced this pull request Dec 30, 2024
tedyu pushed a commit to tedyu/kafka that referenced this pull request Jan 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

build Gradle build or GitHub Actions ci-approved

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants