[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown

[ https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15476104#comment-15476104 ] Steffen Offermann commented on LOG4J2-1259: --- The test case basically looks like

JIRA references in Git commits

Hey, guys! Any chance that you could add the corresponding JIRA ticket number to your Git commits? That would make it MUCH easier to see what's happening. Right now the Git comments don't make any sense to me in 95% of all cases. Regards, Steffen -- aixigo AG - financial solutions & technol

[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown

[ https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15475189#comment-15475189 ] Gary Gregory edited comment on LOG4J2-1259 at 9/9/16 2:28 AM: -

Re: Async tests with ListAppender

To answer your original question should ListAppender internally use CopyOnWriteArrayList, probably yes. There is certainly no harm and it might prevent unpredictable behavior. Also, ListAppender actually provides a CountDownLatch that you can set in the test (before logging) with the expected

Re: Async tests with ListAppender

I'm pretty sure I've "fixed" AsyncAppender for now. The test needs to wait long enough is all. Feel free to check the current version and AsyncAppender and tell me what you think. Gary On Thu, Sep 8, 2016 at 4:26 PM, Remko Popma wrote: > Ah, you're if it's possible that the reason the AsyncAppe

Re: Async tests with ListAppender

Ah, you're if it's possible that the reason the AsyncAppender test is failing is because of a concurrency issue in ListAppender. It is possible when the queue is full: our recent change to the DefaultAsyncQueueFullPolicy is to log synchronously when the queue is full. This is also used in AsyncA

Jenkins build is back to stable : Log4j 2.x #2286

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Async tests with ListAppender

Do we have tests that are async (I'd say yes of course) and that could loose events in a list appender (I do not know)? Are we getting lucky? IOW, do we have the kind of async tests that end up stressing the system in a way were we could loose events in a list appender (don't know). If we do not, s

Re: Async tests with ListAppender

So why are you asking? Ralph > On Sep 8, 2016, at 2:45 PM, Gary Gregory wrote: > > On Thu, Sep 8, 2016 at 2:00 PM, Ralph Goers > wrote: > Why would it? Do you have multiple threads logging? It wasn’t written to be > used by anything but single threaded unit

Jenkins build is still unstable: Log4j 2.x #2285

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: "sys" properties lookup regression

Good catch! This must be a regression caused by the change made to support value attribute in Property elements (https://issues.apache.org/jira/browse/LOG4J2-1313) Sent from my iPhone > On 2016/09/09, at 6:48, Leon Finker wrote: > > Hi, > > Testing master branch.. We have the following xml co

[jira] [Comment Edited] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown

[ https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15475189#comment-15475189 ] Gary Gregory edited comment on LOG4J2-1259 at 9/8/16 10:19 PM:

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown

[ https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15475189#comment-15475189 ] Gary Gregory commented on LOG4J2-1259: -- I've restore binary compatibility for Trigge

"sys" properties lookup regression

Hi, Testing master branch.. We have the following xml configuration: .. .. -- or you can have doesn't matter for the issue And assume there is no 'additionalProp' System property set. On master branch, ${sys:additionalProp} doesn't get resolved and remains as literal ${sys:additionalProp}.

Re: Async tests with ListAppender

On Thu, Sep 8, 2016 at 2:00 PM, Ralph Goers wrote: > Why would it? Do you have multiple threads logging? It wasn’t written to > be used by anything but single threaded unit tests. > I do not have multiple threads logging in a test but I do not know if there is one such test in the whole suite.

Jenkins build is still unstable: Log4j 2.x #2284

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Async tests with ListAppender

Why would it? Do you have multiple threads logging? It wasn’t written to be used by anything but single threaded unit tests. Ralph > On Sep 8, 2016, at 1:34 PM, Gary Gregory wrote: > > Should ListAppender use CopyOnWriteArray instead of ArrayList? Either all the > time or when using in aync t

Async tests with ListAppender

Should ListAppender use CopyOnWriteArray instead of ArrayList? Either all the time or when using in aync tests? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition

Re: 2.6.3-SNAPSHOT java.lang.NoSuchMethodError

FWIW: When I look at Pivotal GemFire 8.2.1 (the latest I could get a non-native version), I see it uses Log4j 2.1. Gary On Thu, Sep 8, 2016 at 12:00 PM, Gary Gregory wrote: > What version of Gemfire are you using? > > Gary > > On Thu, Sep 8, 2016 at 10:40 AM, Leon Finker wrote: > >> Hi, >> >>

Re: 2.6.3-SNAPSHOT java.lang.NoSuchMethodError

Works. Thank you! On 2016-09-08 14:55 (-0400), Gary Gregory wrote: > I've added back the LoggerConfig.createLogger() factory method in Git > master. Please try again. > > Gary > > On Thu, Sep 8, 2016 at 11:43 AM, Gary Gregory > wrote: > > > Fixing... > > > > On Thu, Sep 8, 2016 at 10:40 AM,

Jenkins build became unstable: Log4j 2.x #2283

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Created] (LOG4J2-1571) Example of extending Appenders tries to extend from final class OutputStreamAppender

Adam A. Koch created LOG4J2-1571: Summary: Example of extending Appenders tries to extend from final class OutputStreamAppender Key: LOG4J2-1571 URL: https://issues.apache.org/jira/browse/LOG4J2-1571

Re: 2.6.3-SNAPSHOT java.lang.NoSuchMethodError

8.2.0.13. -- [gemfire-8.2.0.13.jar:?] Actually I double checked and they are on 2.1. Even latest version 8.2.1.1. I don't think they'll be in any hurry to upgrade. On 2016-09-08 15:00 (-0400), Gary Gregory wrote: > What version of Gemfire are you using? > > Gary > > On Thu, Sep 8, 2016 at 1

Re: logging-log4j2 git commit: Fix class loader deadlock when using async logging and extended stack trace pattern

Should they have the same name? Gary On Thu, Sep 8, 2016 at 11:24 AM, Matt Sicker wrote: > I actually don't know any good reason why they have different names. Most > of the code used to exist in log4j-core, but a bunch of it was useful in > log4j-api, so it's been slowly moved to the util pack

[jira] [Closed] (LOG4J2-1546) Remove deprecated Core API Remove deprecated Core API org.apache.logging.log4j.core.config.LoggerConfig.createLogger(String, Level, String, String , AppenderRef[] refs, P

[ https://issues.apache.org/jira/browse/LOG4J2-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-1546. > Remove deprecated Core API Remove deprecated Core API > org.apache.logging.log4j.core.config.LoggerC

Re: 2.6.3-SNAPSHOT java.lang.NoSuchMethodError

What version of Gemfire are you using? Gary On Thu, Sep 8, 2016 at 10:40 AM, Leon Finker wrote: > Hi, > > We are using 3rd part library that depends on log4j2 2.3 API. While > testing latest log4j2 master, our process fails to start. Unless this API > is compatible there is no way to upgrade to

[jira] [Resolved] (LOG4J2-1546) Remove deprecated Core API Remove deprecated Core API org.apache.logging.log4j.core.config.LoggerConfig.createLogger(String, Level, String, String , AppenderRef[] refs,

[ https://issues.apache.org/jira/browse/LOG4J2-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved LOG4J2-1546. -- Resolution: Won't Fix Reverted commit and resolving as "Won't Fix". A user reported breakage in

[jira] [Reopened] (LOG4J2-1546) Remove deprecated Core API Remove deprecated Core API org.apache.logging.log4j.core.config.LoggerConfig.createLogger(String, Level, String, String , AppenderRef[] refs,

[ https://issues.apache.org/jira/browse/LOG4J2-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory reopened LOG4J2-1546: -- > Remove deprecated Core API Remove deprecated Core API > org.apache.logging.log4j.core.config.Log

Re: 2.6.3-SNAPSHOT java.lang.NoSuchMethodError

I've added back the LoggerConfig.createLogger() factory method in Git master. Please try again. Gary On Thu, Sep 8, 2016 at 11:43 AM, Gary Gregory wrote: > Fixing... > > On Thu, Sep 8, 2016 at 10:40 AM, Leon Finker wrote: > >> Hi, >> >> We are using 3rd part library that depends on log4j2 2.3

Re: 2.6.3-SNAPSHOT java.lang.NoSuchMethodError

Fixing... On Thu, Sep 8, 2016 at 10:40 AM, Leon Finker wrote: > Hi, > > We are using 3rd part library that depends on log4j2 2.3 API. While > testing latest log4j2 master, our process fails to start. Unless this API > is compatible there is no way to upgrade to log4j2 2.7. Can this be fixed? > >

Re: logging-log4j2 git commit: Fix class loader deadlock when using async logging and extended stack trace pattern

I actually don't know any good reason why they have different names. Most of the code used to exist in log4j-core, but a bunch of it was useful in log4j-api, so it's been slowly moved to the util package there. On 8 September 2016 at 13:07, Gary Gregory wrote: > I think org.apache.logging.log4j.

Re: logging-log4j2 git commit: Fix class loader deadlock when using async logging and extended stack trace pattern

I think org.apache.logging.log4j.util.LoaderUtil and org.apache.logging.log4j.core.util.Loader. It's also not clear why one is called "Util" and the other not. This is all probably nit-picking since these are both internal classes but it will help anyone looking at the code including us. It's al

Re: 2.6.3-SNAPSHOT java.lang.NoSuchMethodError

It's this commit facb281ba2f5f83903a7aedf385f83d7f9520561 * Remove internal method that is @deprecated Use {@link #createLogger(boolean, Level, String, String, AppenderRef[], Property[], Configuration, Filter)} But it was public, not internal. In any case I wouldn't care if major 3rd party librar

Re: 2.6.3-SNAPSHOT java.lang.NoSuchMethodError

Thanks for pointing this out. There is currently a discussion on the dev list about what we want to remain backward compatible in Log4j core. AppenderRef is certainly one of the things that should be. Ralph > On Sep 8, 2016, at 10:40 AM, Leon Finker wrote: > > Hi, > > We are using 3rd part l

2.6.3-SNAPSHOT java.lang.NoSuchMethodError

Hi, We are using 3rd part library that depends on log4j2 2.3 API. While testing latest log4j2 master, our process fails to start. Unless this API is compatible there is no way to upgrade to log4j2 2.7. Can this be fixed? [2016-09-08 17:16:54,153Z][FATAL][main:0xf][...] java.lang.NoSuchMethodErr

Re: logging-log4j2 git commit: Fix class loader deadlock when using async logging and extended stack trace pattern

Which ones? On 8 September 2016 at 12:27, Gary Gregory wrote: > Good to know. Can the Javadocs be improved? > > Gary > > On Thu, Sep 8, 2016 at 9:39 AM, Matt Sicker wrote: > >> I'm not using the loader utils here because we already have the >> ClassLoader required. The use of LoaderUtil tends t

Re: logging-log4j2 git commit: Fix class loader deadlock when using async logging and extended stack trace pattern

Good to know. Can the Javadocs be improved? Gary On Thu, Sep 8, 2016 at 9:39 AM, Matt Sicker wrote: > I'm not using the loader utils here because we already have the > ClassLoader required. The use of LoaderUtil tends to be where we don't know > which ClassLoader to use. > > On 8 September 2016

[jira] [Closed] (LOG4J2-1457) Class loader deadlock when using async logging and extended stack trace pattern

[ https://issues.apache.org/jira/browse/LOG4J2-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker closed LOG4J2-1457. --- Thanks for the confirmation and the help fixing this! > Class loader deadlock when using async logging a

[jira] [Commented] (LOG4J2-1457) Class loader deadlock when using async logging and extended stack trace pattern

[ https://issues.apache.org/jira/browse/LOG4J2-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15474441#comment-15474441 ] Leon Finker commented on LOG4J2-1457: - Confirmed. NOTE: now that log42 is using Defau

Re: logging-log4j2 git commit: Fix class loader deadlock when using async logging and extended stack trace pattern

I'm not using the loader utils here because we already have the ClassLoader required. The use of LoaderUtil tends to be where we don't know which ClassLoader to use. On 8 September 2016 at 11:09, Gary Gregory wrote: > Hi Matt, > > When I look at the change in ThrowableProxy that go away from usi

Re: [1/2] logging-log4j2 git commit: Remove obsolete comment

That would be great, but I do not see why the primary source of documentation (the Javadoc) should be deleted in the first place. When I am in an IDE whizzing around and coding, I use the Javadoc popups first instead of going to a web browser. Gary On Thu, Sep 8, 2016 at 8:33 AM, Ralph Goers wro

Re: logging-log4j2 git commit: Fix class loader deadlock when using async logging and extended stack trace pattern

Hi Matt, When I look at the change in ThrowableProxy that go away from using our Loader utils and go back to loading classes directly I find it confusing: Are the Loader utils broken or are these call sites the wrong use case for the utils? We (you IIRC) have made a point of using these Loader uti

Re: [1/2] logging-log4j2 git commit: Remove obsolete comment

Why wouldn’t we add information about Log4j 1 to the Migration page? Ralph > On Sep 8, 2016, at 8:13 AM, Gary Gregory wrote: > > That's just silly IMO, Jira is not a place people go to to read > documentation, I could understand if you sent out a link to the site... > > > > Gary > > > On

[jira] [Resolved] (LOG4J2-1457) Class loader deadlock when using async logging and extended stack trace pattern

[ https://issues.apache.org/jira/browse/LOG4J2-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker resolved LOG4J2-1457. - Resolution: Fixed I've added your unit tests along with a simpler fix in ThrowableProxy to the m

[jira] [Updated] (LOG4J2-1457) Class loader deadlock when using async logging and extended stack trace pattern

[ https://issues.apache.org/jira/browse/LOG4J2-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-1457: Summary: Class loader deadlock when using async logging and extended stack trace pattern (was: Cla

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown

[ https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15474125#comment-15474125 ] Gary Gregory commented on LOG4J2-1259: -- What is your failing test? > Log4j threads

Re: [1/2] logging-log4j2 git commit: Remove obsolete comment

That's just silly IMO, Jira is not a place people go to to read documentation, I could understand if you sent out a link to the site... Gary On Sep 8, 2016 1:45 AM, "Mikael Ståldal" wrote: > In https://issues.apache.org/jira/browse/LOG4J2-1523 > > > On Wed, Sep 7, 2016 at 8:26 PM, Gary Gregory

[jira] [Comment Edited] (LOG4J2-1457) Class loader deadlock when using async logging

[ https://issues.apache.org/jira/browse/LOG4J2-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15474097#comment-15474097 ] Matt Sicker edited comment on LOG4J2-1457 at 9/8/16 3:11 PM: -

[jira] [Commented] (LOG4J2-1528) Serialize configuration into a log4j2.xml file

[ https://issues.apache.org/jira/browse/LOG4J2-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15474107#comment-15474107 ] Gary Gregory commented on LOG4J2-1528: -- Cool, thank you. > Serialize configuration

[jira] [Commented] (LOG4J2-1457) Class loader deadlock when using async logging

[ https://issues.apache.org/jira/browse/LOG4J2-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15474097#comment-15474097 ] Matt Sicker commented on LOG4J2-1457: - Taking a closer look at this issue again, I co

[jira] [Commented] (LOG4J2-1457) Class loader deadlock when using async logging

[ https://issues.apache.org/jira/browse/LOG4J2-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15474007#comment-15474007 ] Matt Sicker commented on LOG4J2-1457: - Yeah, I'll take a look at this again today. >

Re: [1/2] logging-log4j2 git commit: Deprecate org.apache.logging.log4j.core.util.NullOutputStream.NULL_OUTPUT_STREAM in favor of org.apache.logging.log4j.core.util.NullOutputStream.getInstance().

We can just convert everything to LF. Needs to be done on all active branches, though, or else we'll get crazy merge conflicts I think. On 8 September 2016 at 02:15, Gary Gregory wrote: > Let's all agree to 'something' and have that 'something' tested. Then we > can add it to our site docs. > >

[jira] [Commented] (LOG4J2-1457) Class loader deadlock when using async logging

[ https://issues.apache.org/jira/browse/LOG4J2-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473951#comment-15473951 ] Leon Finker commented on LOG4J2-1457: - Matt, can this make it into 2.7? > Class loa

[jira] [Issue Comment Deleted] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown

[ https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steffen Offermann updated LOG4J2-1259: -- Comment: was deleted (was: Now {{CronTriggeringPolicy.stop()}} does get called - but th

Re: Deprecated factory methods replaced by builders.

What about them? Do they fit into the category of anything I have described? No. Ralph > On Sep 7, 2016, at 10:18 PM, Gary Gregory wrote: > > What about code in the Core util package? > > Gary > >> On Wed, Sep 7, 2016 at 10:06 PM, Ralph Goers >> wrote: >> Everything is internal, but as I sa

[jira] [Commented] (LOG4J2-1528) Serialize configuration into a log4j2.xml file

[ https://issues.apache.org/jira/browse/LOG4J2-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473306#comment-15473306 ] Mikael Ståldal commented on LOG4J2-1528: I changed it to two spaces for indention

Re: [1/2] logging-log4j2 git commit: Remove obsolete comment

In https://issues.apache.org/jira/browse/LOG4J2-1523 On Wed, Sep 7, 2016 at 8:26 PM, Gary Gregory wrote: > How do you know what is supported then? > > Gary > > -- Forwarded message -- > From: > Date: Wed, Sep 7, 2016 at 12:15 PM > Subject: [1/2] logging-log4j2 git commit: Remov

Re: logging-log4j2 git commit: Fix POM description.

"warpper" should be wrapper. Sent from my iPhone > On 2016/09/08, at 13:47, ggreg...@apache.org wrote: > > Repository: logging-log4j2 > Updated Branches: > refs/heads/master f2a7f74ec -> 1d3dc77cf > > > Fix POM description. > > Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown

[ https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473144#comment-15473144 ] Steffen Offermann commented on LOG4J2-1259: --- Go rest! My day has just begun. :)

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown

[ https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473122#comment-15473122 ] Gary Gregory commented on LOG4J2-1259: -- Arg, good catch again. Time for rest after a

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown

[ https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473100#comment-15473100 ] Steffen Offermann commented on LOG4J2-1259: --- Now {{CronTriggeringPolicy.stop()}

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown

[ https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473076#comment-15473076 ] Steffen Offermann commented on LOG4J2-1259: --- Will do in a minute, Gary. I just

Re: [1/2] logging-log4j2 git commit: Deprecate org.apache.logging.log4j.core.util.NullOutputStream.NULL_OUTPUT_STREAM in favor of org.apache.logging.log4j.core.util.NullOutputStream.getInstance().

Let's all agree to 'something' and have that 'something' tested. Then we can add it to our site docs. Gary On Thu, Sep 8, 2016 at 12:10 AM, Remko Popma wrote: > Guys, would it be possible to do something about the commit mails showing > all lines as changed? > > It seems that we need to take tw

[jira] [Closed] (LOG4J2-1567) DynamicThresholdFilter

[ https://issues.apache.org/jira/browse/LOG4J2-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jdumetier closed LOG4J2-1567. - > DynamicThresholdFilter > --- > > Key: LOG4J2-1567 > UR

Re: Deprecated factory methods replaced by builders.

Note that I said "for removed code". Clirr will also complain about methods added but I did not show that. Sadly, Clirr does not complain about methods being added via a change in inheritance. Clirr is ld... Gary On Thu, Sep 8, 2016 at 12:00 AM, Remko Popma wrote: > Interesting, so Clir

Re: [1/2] logging-log4j2 git commit: Deprecate org.apache.logging.log4j.core.util.NullOutputStream.NULL_OUTPUT_STREAM in favor of org.apache.logging.log4j.core.util.NullOutputStream.getInstance().

Guys, would it be possible to do something about the commit mails showing all lines as changed? It seems that we need to take two steps: 1. Change Eclipse settings: http://stackoverflow.com/a/24337518/1446916 2. Convert CRLF to unix LF in existing files. Apparently there's no need to configure

[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on tomcat shutdown

[ https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473043#comment-15473043 ] Gary Gregory commented on LOG4J2-1259: -- Hi [~SteffenO]: Nice find and my bad! I imp

Re: Deprecated factory methods replaced by builders.

Interesting, so Clirr does not detect the breaking change to TriggeringPolicy. Sent from my iPhone > On 2016/09/08, at 13:32, Gary Gregory wrote: > > FWIW, here is what Clirr finds for removed code: > > [ERROR] 7002: org.apache.logging.log4j.core.appender.ConsoleAppender$Builder: > Method 'p