You are correct. And after looking at the class and at Liquibase master this
code is now completely broken and should be dropped. 3.5.3 is the latest
Liquibase release and the code possibly still works with that, although the
unit tests certainly don’t prove that. But the code in master has been
>From when I used log4j-liquibase in the past, it doesn't log _to_
liquibase; instead, it offers an implementation of its internal logger
logic which doesn't use any existing facade by default.
On 14 January 2018 at 17:14, Ralph Goers wrote:
> Ok.
>
> If we do this we should release that before
Ok.
If we do this we should release that before we remove them from a Log4J release
to minimize confusion.
Sent from my iPhone
> On Jan 14, 2018, at 3:47 PM, Remko Popma wrote:
>
> No objection from me.
>
> Let’s make it a community goal to speed up the Log4j2 build. We should start
> by c
No objection from me.
Let’s make it a community goal to speed up the Log4j2 build. We should start by
creating a JIRA epic (it’s in maintenance now but when it’s back up).
(Shameless plug) Every java main() method deserves http://picocli.info
> On Jan 15, 2018, at 6:11, Ralph Goers wrote:
>
I don’t believe the components listed in the subject line should be part of the
main flume build and would like to see them moved to the logging-log4j-plugins
project. The only problem is that the modules and maven coordinates need to
change since the version numbers will be going backwards. I w
I’m hoping to complete https://issues.apache.org/jira/browse/LOG4J2-1883 in a
week or two.
That would bring a new log4j-core-java9 module and should probably be called
2.11 if that can be included.
Remko
(Shameless plug) Every java main() method deserves http://picocli.info
> On Jan 14, 20
Will the next release be 2.10.1 or 2.11.0?
If 2.10.1, I start seeing a few new features in master branch that might
not be appropriate for a patch release.
