[ https://issues.apache.org/jira/browse/CALCITE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17457777#comment-17457777 ]
Jacques Nadeau edited comment on CALCITE-4935 at 12/12/21, 12:07 AM: --------------------------------------------------------------------- I don't really understand the expectation of shading here. Generally speaking, things should be one of the two following options: 1. This is a jar used within another application (far dependency jar). In that case, the standard pattern is to only include slf4j apis (unshaded) and let users bring their own logging implementation. 2. This is a jar used as a standalone server (easy to run/deploy single jar). In that case, there is no reason to shade dependencies as it isn't designed to be run in another application. People should be able to use standard logging configuration patterns. Including logging impl but shading it makes it hard to deal configure/control logging consistently in #1. That being said, if we really think the impl should be included and shaded (neither 1 nor 2 above), it looks like there may be need to merge some internal log4j2 files using a special transformer. See https://github.com/johnrengelman/shadow/issues/207, https://github.com/edwgiz/maven-shaded-log4j-transformer and https://issues.apache.org/jira/browse/LOG4J2-673. was (Author: jnadeau): I don't really understand the expectation of shading here. Generally speaking, things should be one of the two following options: 1. This is a jar used within another application (far dependency jar). In that case, the standard pattern is to only include slf4j apis (unshaded) and let users bring their own logging implementation. 2. This is a jar used as a standalone server (easy to run/deploy single jar). In that case, there is no reason to shade dependencies as it isn't designed to be run in another application. People should be able to use standard patterns to configure. Including logging impl but shading it makes it hard to deal configure/control logging consistently in #1. That being said, if we really think the impl should be included and shaded (neither 1 nor 2 above), it looks like there may be need to merge some internal log4j2 files using a special transformer. See https://github.com/johnrengelman/shadow/issues/207, https://github.com/edwgiz/maven-shaded-log4j-transformer and https://issues.apache.org/jira/browse/LOG4J2-673. > Avatica standalone-server shades log4j without relocation > --------------------------------------------------------- > > Key: CALCITE-4935 > URL: https://issues.apache.org/jira/browse/CALCITE-4935 > Project: Calcite > Issue Type: Bug > Components: avatica > Reporter: Stamatis Zampetakis > Assignee: Stamatis Zampetakis > Priority: Major > Fix For: avatica-1.20.0 > > Attachments: screenshot-1.png > > > The issue has been found during the vote for avatica-1.20.0 RC0. > The standalone-server jar in the [staged maven > repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar] > contains log4j2 classes but they are not relocated. > In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all > relocated to avoid classpath problems with other libraries/apps potentially > using another log4j2 version. > It seems that relocation was dropped in possibly unintenionally in > CALCITE-4152. -- This message was sent by Atlassian Jira (v8.20.1#820001)