You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by GitBox <gi...@apache.org> on 2021/06/02 20:16:54 UTC
[GitHub] [logging-log4j2] nvoxland opened a new pull request #503: Liquibase 4.x Compatibility
nvoxland opened a new pull request #503:
URL: https://github.com/apache/logging-log4j2/pull/503
## Overview
Liquibase 3.6 as well as 4.0 introduced API compatibility issues with the current log4j-liquibase codebase. See liquibase/liquibase#1777
This updates the code to be compatible with 4.0+ while still supporting 3.5 and 3.6+ users.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] camsaul commented on pull request #503: Liquibase 4.x Compatibility
Posted by GitBox <gi...@apache.org>.
camsaul commented on pull request #503:
URL: https://github.com/apache/logging-log4j2/pull/503#issuecomment-1065350227
For anyone looking for a workaround I was able to resolve this by adding a dependency on `log4j-jul` https://github.com/metabase/metabase/pull/20611/files#diff-551f87f7577a57c2f4f74b35056d5c7985331f7a38976810fd2bbc213bfe7bb5R87 and installing the bridge at runtime
https://github.com/metabase/metabase/pull/20611/files#diff-7b84b53f388126bbf994fbdb5b705a6eefeaf0999da00dc45a40a6559f85ac30R23-R28
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] nvoxland commented on pull request #503: Liquibase 4.x Compatibility
Posted by GitBox <gi...@apache.org>.
nvoxland commented on pull request #503:
URL: https://github.com/apache/logging-log4j2/pull/503#issuecomment-853355519
With the new Log4j2Logger implementation, the messages coming through in the test class look like ` liquibase.ext.logging.log4j2.Log4j2LoggerTest liquibase.logging.core.AbstractLogger FATAL Severe message` and I'm not sure where that "AbractLogger" part is coming from.
I think I'm setting up the ExtendedLogger the same as it was in the old code, but that extra piece is not showing up there.
Any ideas why?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] vy commented on pull request #503: Liquibase 4.x Compatibility
Posted by GitBox <gi...@apache.org>.
vy commented on pull request #503:
URL: https://github.com/apache/logging-log4j2/pull/503#issuecomment-857129855
Hey @nvoxland, thanks for the contribution. I have my concerns if Log4j should have a Liquibase-specific module in the first place. Let me elaborate on that a bit.
Certain libraries, which is Liquibase in this particular case, create their own logging API rather than choosing one available in the market, e.g., slf4j-api, log4j-api. Consequently, they contribute to logging backends (Logback, Log4j, etc.) with implementations of their custom logging API. This, IMHO, contradicts with the motives of those logging backends shipping a separate API in the first place. I would rather prefer Liquibase logging against, say, the Log4j API and let users pick a backend. For instance, users then can either employ any backend supporting Log4j API (e.g., Log4j itself) or use a bridge to port it to another API of their preference (e.g., using log4j-to-slf4j bridge in combination with Logback).
In your profile, I see that you are member of the Liquibase organization. Would you mind telling us why can't Liquibase simply use Log4j API instead? Are there any technical limitations I miss here?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] nvoxland commented on pull request #503: Liquibase 4.x Compatibility
Posted by GitBox <gi...@apache.org>.
nvoxland commented on pull request #503:
URL: https://github.com/apache/logging-log4j2/pull/503#issuecomment-857912131
From Liquibase's standpoint, as a library we try hard not to introduce dependencies on external libraries such as log4j. Therefore, we build off the java.util.Logger but do have a lightweight extension point where 3rd parties can plug in alternatives instead.
This code is really just plugging into that liquibase extension point to bypass JUL and go directly to log4j. An alternative is certainly to use the log4j-jul adapter as well. I didn't write this extension in the code here, just fixing it :)
If you are against continuing to have this extension as part of log4j, we could look at bringing it into the liquibase codebase directly as well. I don't think we could have it automatically enabled if log4j is found, since many users end up with log4j in their classpath even though it's not their "real" logging system. But, have some configuration settings we could support.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] nvoxland commented on pull request #503: Liquibase 4.x Compatibility
Posted by GitBox <gi...@apache.org>.
nvoxland commented on pull request #503:
URL: https://github.com/apache/logging-log4j2/pull/503#issuecomment-858686682
Yes, I will keep the rest of the team up on this discussion.
I think that making log4j-api a required part of our API or standard logging implementation is a no-go. It would mean having to change a stable API, and impacts users embedding liquibase but not wanting to introduce log4j-api as a dependency into their software.
But, there are ways we can include it in liquibase so log4j isn't required but still would work when people already have it as a dependency.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] rgoers commented on pull request #503: Liquibase 4.x Compatibility
Posted by GitBox <gi...@apache.org>.
rgoers commented on pull request #503:
URL: https://github.com/apache/logging-log4j2/pull/503#issuecomment-858745835
I don't necessarily object to Log4j providing integrations with third party components. But if something like liquibase chooses to provide its own logging API then it should also supply the bindings to the various implementations its users want to use. That binding could certainly be hosted inside the Log4j project, but it really shouldn't be part of the main Log4j release. We can't possibly support every such integration in that way.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] vy commented on pull request #503: Liquibase 4.x Compatibility
Posted by GitBox <gi...@apache.org>.
vy commented on pull request #503:
URL: https://github.com/apache/logging-log4j2/pull/503#issuecomment-858579063
I perfectly understand your conservative attitude for adding dependencies to your project and share them. This said, dependencies increase re-usability and independent evolution. Hence, I ~strongly~ kindly advice you to consider adopting `log4j-api`, if possible.
Even though I am a PMC member, I cannot speak for the rest of the board. I will raise this issue in the `dev` mailing list. If we decide to exclude `log4j-liquibase` from `3.x` onward, I see two possible paths:
1. Liquibase adopting `log4j-api` (recommended)
1. Introducing `liquibase-log4j` module (I already see a `org.liquibase.ext:liquibase-javalogger` module)
For the records, would you mind sharing this with the rest of Liquibase crew and let us know what do you think, please? Is adopting `log4j-api` really a no-go for you?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org