I set the test to @Ignore so I could continue working.
Ralph
On Jul 17, 2013, at 7:21 PM, Gary Gregory wrote:
> The test is now called XmlCompactFileAsyncAppenderValidationTest and is still
> not working.
>
> The test XmlCompactFileAppenderValidationTest is no longer async and works.
>
> I'd
[
https://issues.apache.org/jira/browse/LOG4J2-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-299.
Resolution: Fixed
Fix Version/s: 2.0-beta9
getThrowable was added in revision 1504373. Pleas
[
https://issues.apache.org/jira/browse/LOG4J2-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-216.
Resolution: Fixed
Fix Version/s: 2.0-beta9
Most of this was resolved in revision 1504373. Ho
I will say that the one thing that is missing is a page on the Log4j 2 web site
like http://www.slf4j.org/legacy.html that documents these components (with
similar pretty pictures) and compares them with what is offered by SLF4J.
Ralph
On Jul 17, 2013, at 10:13 PM, Ralph Goers wrote:
> Also,
This looks good to me.
Ralph
On Jul 17, 2013, at 6:43 PM, Nick Williams wrote:
> They are. Like I told Ralph, the link was just a screenshot, so that was
> chopped off.
>
> Hopefully this will be less confusing:
> http://people.apache.org/~nickwilliams/log4j-site/
>
> Nick
>
> On Jul 17, 20
The ErrorHandler is there primarily to avoid endlessly logging the same error
message every time a log event fails in the appender. Unfortunately, this
isn't used consistently and it is difficult to use from Managers, which is
where most of the errors are going to occur.
Ralph
On Jul 17, 2013
I do not have a problem with renaming handleExceptions to exceptionSuppressed.
I do have a problem with renaming supressExceptions to ignoreExceptions,
primarily because I have a bunch of teams using Log4j 2 in production and they
would have to modify their configurations when they upgrade. Fu
Also, "binding" is the term SLF4J uses for implementations of its API, so that
should make sense to SLF4J users looking for implementations. Log4j 1.2 is an
implementation of that API - the "real" log4j 1.x jars should not be used. The
JCL bridge is exactly that, a bridge between the Commons L
We have already renamed these at least twice. Just leave them be.
Sent from my iPad
On Jul 17, 2013, at 7:07 PM, Remko Popma wrote:
>
> Currently we have three different names for things that provide a
> bridge/adapter from other logging APIs to the Log4j2 implementation:
> (Commons Logging)
I'll reply when I'm in front of my computer
Sent from my iPad
On Jul 17, 2013, at 7:15 PM, Nick Williams
wrote:
> I'd like to get Paul's and Ralph's feedback before I make this change.
>
> Nick
>
> On Jul 17, 2013, at 7:28 PM, Gary Gregory wrote:
>
>> On Jul 17, 2013, at 20:11, Nick William
I believe I created that class to test the performance of the Reflection class,
so what it does isn't too important.
Sent from my iPad
On Jul 17, 2013, at 6:55 PM, Gary Gregory wrote:
> Hi all,
>
> If you scan the source for all senders of "printStackTrace" you'll find 21
> references.
>
>
So much better.
On Wed, Jul 17, 2013 at 10:12 PM, Gary Gregory wrote:
>
> On Jul 17, 2013, at 22:40, Nick Williams
> wrote:
>
> Yea I think we all go that. Important part is:
>
> - "log4j-1.2-api" becomes "log4j-1.2-bridge" and is named "Log4j 1.2
> Bridge"
> - "log4j-jcl" becomes "log4j-jcl-br
On Jul 17, 2013, at 22:40, Nick Williams
wrote:
Yea I think we all go that. Important part is:
- "log4j-1.2-api" becomes "log4j-1.2-bridge" and is named "Log4j 1.2 Bridge"
- "log4j-jcl" becomes "log4j-jcl-bridge" and is named "Commons Logging
Bridge"
- "log4j-slf4j-impl" becomes "log4j-slf4j-bri
On Jul 17, 2013, at 22:36, Nick Williams
wrote:
Guys, it's been six weeks since we last discussed this. Several of us are
pushing to get Log4j2 released GA next month or very early in September.
Can we get this moving? It'd be great to have the new logo for the GA
release.
I'd love to see a log
On Jul 17, 2013, at 22:26, Nick Williams
wrote:
What problem are you referring to? "org.xml.sax.SAXParseException: XML
document structures must start and end within the same entity.",
"java.io.FileNotFoundException:
/trunk/target/XmlCompactFileAppenderValidationTest.log.xml",
or something else?
Yea I think we all go that. Important part is:
- "log4j-1.2-api" becomes "log4j-1.2-bridge" and is named "Log4j 1.2 Bridge"
- "log4j-jcl" becomes "log4j-jcl-bridge" and is named "Commons Logging Bridge"
- "log4j-slf4j-impl" becomes "log4j-slf4j-bridge" and is named "SLF4J Bridge"
Consistency is a
Small correction: I'd like to rename the log4j-1.2-api jar to
log4j-1.2-bridge-2.0.jar (without api in the name).
Sent from my iPhone
On 2013/07/18, at 11:07, Remko Popma wrote:
>
> Currently we have three different names for things that provide a
> bridge/adapter from other logging APIs to
Guys, it's been six weeks since we last discussed this. Several of us are
pushing to get Log4j2 released GA next month or very early in September. Can we
get this moving? It'd be great to have the new logo for the GA release.
Nick
On Jun 3, 2013, at 12:10 AM, Christian Grobmeier wrote:
> Sorry
I'll take a look at this later.
-Remko
Yea, I get mixed up between the two different SLF4J components all the time. If
all the bridges were actually called "bridge," it would be way less confusing
for me. If it's confusing for me and it's confusing for Gary, you know it's
going to be confusing for the users.
Nick
On Jul 17, 2013, a
What problem are you referring to? "org.xml.sax.SAXParseException: XML document
structures must start and end within the same entity.",
"java.io.FileNotFoundException:
/trunk/target/XmlCompactFileAppenderValidationTest.log.xml", or something else?
I have seen problems before when unit testing i
I also find the inconsistency in naming confusing. I always have to read
the description to remind myself what direction a module follows.
Gary
On Wed, Jul 17, 2013 at 10:11 PM, Nick Williams <
[email protected]> wrote:
> Agreed, on all counts.
>
> Nick
>
>
> On Jul 17, 2013, at 9:
The test is now called XmlCompactFileAsyncAppenderValidationTest and is
still not working.
The test XmlCompactFileAppenderValidationTest is no longer async and works.
I'd like to know if the way the async test is written is supposed to work
or not because I cloned the pattern from another test. I
I am good with #ignoreExceptions()
On Wed, Jul 17, 2013 at 9:15 PM, Nick Williams <
[email protected]> wrote:
> I'd like to get Paul's and Ralph's feedback before I make this change.
>
> Nick
>
> On Jul 17, 2013, at 7:28 PM, Gary Gregory wrote:
>
> > On Jul 17, 2013, at 20:11, Nick W
I'd like to get Paul's and Ralph's feedback before I make this change.
Nick
On Jul 17, 2013, at 7:28 PM, Gary Gregory wrote:
> On Jul 17, 2013, at 20:11, Nick Williams
> wrote:
>
>> So Appender#ignoreExceptions() and XML/JSON ignoreExceptions? I like that,
>> too.
>
> Yep, that's what I mea
Agreed, on all counts.
Nick
On Jul 17, 2013, at 9:07 PM, Remko Popma wrote:
> Currently we have three different names for things that provide a
> bridge/adapter from other logging APIs to the Log4j2 implementation:
> (Commons Logging) Bridge, (Log4j 1.2) API, and (SLF4J) Binding.
>
> Would it
Currently we have three different names for things that provide a
bridge/adapter from other logging APIs to the Log4j2 implementation:
(Commons Logging) Bridge, (Log4j 1.2) API, and (SLF4J) Binding.
Would it be a good idea to call them all "Bridge"?
On the web site, components would then become:
On Jul 17, 2013, at 8:55 PM, Gary Gregory wrote:
> Hi all,
>
> If you scan the source for all senders of "printStackTrace" you'll find 21
> references.
>
> Are all of those correct instead of logging to StatusLogger or throwing an
> exception
I would say "none of them are correct." Outside
Hi all,
If you scan the source for all senders of "printStackTrace" you'll find 21
references.
Are all of those correct instead of logging to StatusLogger or throwing an
exception or a different exception in the case where this is done in
response to catching an exception.
Also, in some cases l
They are. Like I told Ralph, the link was just a screenshot, so that was
chopped off.
Hopefully this will be less confusing:
http://people.apache.org/~nickwilliams/log4j-site/
Nick
On Jul 17, 2013, at 8:39 PM, Remko Popma wrote:
> I assumed the component reports would be unchanged (and actual
I assumed the component reports would be unchanged (and actually contain the
Javadoc links like they do now)...
Sent from my iPhone
On 2013/07/18, at 10:35, Ralph Goers wrote:
> What did you do with the component reports - RAT, PMD, checkstyle, etc.?
>
> Sent from my iPad
>
> On Jul 17, 2013
Indeed. Thanks.
Nick
On Jul 17, 2013, at 8:28 PM, Remko Popma wrote:
> Looks good!
>
> Small detail: Log4j 1.1 should be 1.2?
>
> Remko
>
> Sent from my iPhone
>
> On 2013/07/18, at 10:16, Nick Williams wrote:
>
>> Take a look at this and let me know what you think.
>>
>> http://people.ap
They're just chopped off on the screenshot. That's just a screenshot of one
window.
Nick
On Jul 17, 2013, at 8:35 PM, Ralph Goers wrote:
> What did you do with the component reports - RAT, PMD, checkstyle, etc.?
>
> Sent from my iPad
>
> On Jul 17, 2013, at 6:16 PM, Nick Williams
> wrote:
>
What did you do with the component reports - RAT, PMD, checkstyle, etc.?
Sent from my iPad
On Jul 17, 2013, at 6:16 PM, Nick Williams
wrote:
> Take a look at this and let me know what you think.
>
> http://people.apache.org/~nickwilliams/Log4j2JavadocMenu.png
>
> I have it staged locally. I'
Looks good!
Small detail: Log4j 1.1 should be 1.2?
Remko
Sent from my iPhone
On 2013/07/18, at 10:16, Nick Williams wrote:
> Take a look at this and let me know what you think.
>
> http://people.apache.org/~nickwilliams/Log4j2JavadocMenu.png
>
> I have it staged locally. I'm ready to commit
Take a look at this and let me know what you think.
http://people.apache.org/~nickwilliams/Log4j2JavadocMenu.png
I have it staged locally. I'm ready to commit unless anyone has any objections
to this approach.
Nick
On Jul 17, 2013, at 7:30 PM, Remko Popma wrote:
> Alternatively we could have
Alternatively we could have a new Javadoc section under the Components section,
with links to the Javadoc for each of the components.
Sent from my iPhone
On 2013/07/18, at 9:27, Gary Gregory wrote:
> On Jul 17, 2013, at 20:06, Remko Popma wrote:
>
>> I wouldn't mind having two links (API Ja
On Jul 17, 2013, at 20:11, Nick Williams wrote:
> So Appender#ignoreExceptions() and XML/JSON ignoreExceptions? I like that,
> too.
Yep, that's what I meant.
Gary
>
> Nick
>
> On Jul 17, 2013, at 7:04 PM, Gary Gregory wrote:
>
>> I think I like the "ignoreExceptions" variation.
>>
>> Gary
>>
>
On Jul 17, 2013, at 20:06, Remko Popma wrote:
> I wouldn't mind having two links (API Javadoc and Core Javadoc) added to the
> bottom of the Manual section.
That sounds good too.
Gary
>
> Remko
>
> Sent from my iPhone
>
> On 2013/07/18, at 8:56, Nick Williams wrote:
>
>> The Javadoc on the s
So Appender#ignoreExceptions() and XML/JSON ignoreExceptions? I like that, too.
Nick
On Jul 17, 2013, at 7:04 PM, Gary Gregory wrote:
> I think I like the "ignoreExceptions" variation.
>
> Gary
>
> On Jul 17, 2013, at 18:39, Nick Williams
> wrote:
>
>> ignoreExceptions
>
>
I wouldn't mind having two links (API Javadoc and Core Javadoc) added to the
bottom of the Manual section.
Remko
Sent from my iPhone
On 2013/07/18, at 8:56, Nick Williams wrote:
> The Javadoc on the site is very non-obvious to find (actually it's just
> downright improbable to find if you d
I think I like the "ignoreExceptions" variation.
Gary
On Jul 17, 2013, at 18:39, Nick Williams wrote:
> ignoreExceptions
-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: log4j
The Javadoc should be at the top level I think. It could be I the
manual too, since it does document the API, as an exhaustive
reference. I agree that it is too hard to find it now.
Gary
On Jul 17, 2013, at 19:56, Nick Williams wrote:
> The Javadoc on the site is very non-obvious to find (actua
The Javadoc on the site is very non-obvious to find (actually it's just
downright improbable to find if you don't already know where to look ... I had
to email the user list and ask where it was the first time I tried to find it).
I'd like to add a dedicated link on the left-hand menu that expan
[
https://issues.apache.org/jira/browse/LOG4J2-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-291.
--
Resolution: Fixed
This is fixed. Please verify with latest (or wait until the next release) and
[
https://issues.apache.org/jira/browse/LOG4J2-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams updated LOG4J2-291:
-
Assignee: Nick Williams
> Failover appender doesn't fail over on JDBC appender error
> --
[
https://issues.apache.org/jira/browse/LOG4J2-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams updated LOG4J2-291:
-
Fix Version/s: 2.0-beta9
> Failover appender doesn't fail over on JDBC appender error
> -
Okay. So there are two things we need to think about here:
1) The Appender interface contains a method named isExceptionSuppressed(). I've
never liked that name anyway (the grammar is awkward). Do we want to rename
this method? Some ideas: areExceptionsIgnored(), shouldIgnoreExceptions(),
ignor
Aren't we really just talking about ignoring exceptions? If so, "ignore" is
much better than "suppressing" for the reason I raised.
On Wed, Jul 17, 2013 at 5:10 PM, Gary Gregory wrote:
> On Wed, Jul 17, 2013 at 5:48 PM, Paul Benedict wrote:
>
>> The phrase "suppressed exception" actually means s
On Wed, Jul 17, 2013 at 5:48 PM, Paul Benedict wrote:
> The phrase "suppressed exception" actually means something specific in the
> JDK. Are you okay with using the same terminology?
>
> http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
>
This is confusing IMO, w
On Wed, Jul 17, 2013 at 2:52 PM, Nick Williams <
[email protected]> wrote:
> Okay, so, proposal: I rename AppenderRuntimeException to
> AppenderLoggingException and change it to extend LoggingException. Like
> LoggingException, it should only be thrown when logging an event fails.
> Th
Hi All:
I've hit a snag testing XML validation.
Please see
org.apache.logging.log4j.core.appender.XmlCompactFileAppenderValidationTest
Is this a quirk of testing because the log file is not closed?
Thank you,
Gary
--
E-Mail: [email protected] | [email protected]
Java Persistence with H
[
https://issues.apache.org/jira/browse/LOG4J2-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13711699#comment-13711699
]
Gary Gregory commented on LOG4J2-312:
-
- Use CamelCase for element names, like class n
[
https://issues.apache.org/jira/browse/LOG4J2-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-312:
Description:
- The XML root element was “eventSet”, it is now “events”. The word “set” is
misleadi
[
https://issues.apache.org/jira/browse/LOG4J2-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved LOG4J2-311.
Resolution: Fixed
Fixed in revision 1504297:
Made close() and flush() methods synchronized in
Fast
[
https://issues.apache.org/jira/browse/LOG4J2-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reassigned LOG4J2-311:
--
Assignee: Remko Popma
> FastFileAppender and FastRollingFileAppender not thread-safe
>
I think it's pretty clear here that Log4j suppressing appender exceptions and
JDK Suppressed Exceptions are not the same thing. I don't think it's something
that we need to worry about, and changing the name to something else (what?)
would require a much bigger refactor (and would be an API-alte
The phrase "suppressed exception" actually means something specific in the
JDK. Are you okay with using the same terminology?
http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
On Wed, Jul 17, 2013 at 4:42 PM, Nick Williams <
[email protected]> wrote:
>
Appender specifies a method, isExceptionSuppressed(), which indicates whether
exceptions thrown while appending events should be suppressed (logged instead
of re-thrown).
AbstractAppender implements this method with a private handleExceptions field
and a handleExceptions constructor argument. i
Okeydokey.
Nick
On Jul 17, 2013, at 3:56 PM, Ralph Goers wrote:
> I see your point. I guess we should leave ConfigurationException alone.
>
> Ralph
>
>
> On Jul 17, 2013, at 1:03 PM, Nick Williams wrote:
>
>> The Javadoc for LoggingException says "Exception thrown when a exception
>> occur
[
https://issues.apache.org/jira/browse/LOG4J2-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13711610#comment-13711610
]
Woonsan Ko commented on LOG4J2-313:
---
Hi,
I've just uploaded a patch to provide built-in
[
https://issues.apache.org/jira/browse/LOG4J2-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13711610#comment-13711610
]
Woonsan Ko edited comment on LOG4J2-313 at 7/17/13 8:56 PM:
Hi
I see your point. I guess we should leave ConfigurationException alone.
Ralph
On Jul 17, 2013, at 1:03 PM, Nick Williams wrote:
> The Javadoc for LoggingException says "Exception thrown when a exception
> occurs while logging." ConfigurationException is never thrown by logging, so
> extend L
[
https://issues.apache.org/jira/browse/LOG4J2-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated LOG4J2-313:
--
Attachment: jndi-lookup-plugin.patch
> JNDI Lookup plugin support
> --
>
>
The Javadoc for LoggingException says "Exception thrown when a exception occurs
while logging." ConfigurationException is never thrown by logging, so extend
LoggingException would change the meaning of LoggingException. Do we want to
change the meaning of LoggingException to encompass all errors
I'm fine with having both AppenderRuntimeException and ConfigurationException
extend LoggingException. I'm fine with renaming AppenderRuntimeException to
AppenderLoggingException.
Ralph
On Jul 17, 2013, at 12:21 PM, Nick Williams wrote:
> So what about my proposal for renaming and changing i
So what about my proposal for renaming and changing inheritance of appender
exception. Thoughts?
Nick
On Jul 17, 2013, at 2:18 PM, Ralph Goers wrote:
> I'd throw the appender exception since the database manager is acting as part
> of the Appender.
>
> Ralph
>
> On Jul 17, 2013, at 11:52 AM,
I think I see something subtle in what you are saying. If your
JDBCDatabaseManager can't connect it shouldn't just fail forever. It should be
capable of performing retries. Thus, the error might occur when logging an
event and then it might establish a new connection for a subsequent event. S
I'd throw the appender exception since the database manager is acting as part
of the Appender.
Ralph
On Jul 17, 2013, at 11:52 AM, Nick Williams wrote:
> Okay, so, proposal: I rename AppenderRuntimeException to
> AppenderLoggingException and change it to extend LoggingException. Like
> Loggin
Okay, so, proposal: I rename AppenderRuntimeException to
AppenderLoggingException and change it to extend LoggingException. Like
LoggingException, it should only be thrown when logging an event fails.
Thoughts?
That still leaves the question of which exception I should throw when my
JDBCDataba
Perhaps AppenderRuntimeException should have extended LoggingException. As you
might expect, AppenderRuntimeException is primarily for Appenders to throw as
they need to. LoggingExceptions are thrown everywhere else. It is likely that
LoggingException is being used in Appenders but those shoul
Based on the name, I would hope that ConfigurationException is only thrown
when a problem is found reading and processing a config file. I've not
looked at this area of Log4j though
Gary
On Wed, Jul 17, 2013 at 2:23 PM, Nick Williams <
[email protected]> wrote:
> I'm working on
I'm working on better exception handling in the DB appenders, and then I'll see
if other appenders are using best practices, too.
Log4j 2 defines three different exceptions: LoggingException in the API and
AppenderRuntimeException and ConfigurationException in Core.
I've pretty much figured out
Woonsan Ko created LOG4J2-313:
-
Summary: JNDI Lookup plugin support
Key: LOG4J2-313
URL: https://issues.apache.org/jira/browse/LOG4J2-313
Project: Log4j 2
Issue Type: New Feature
Repo
How do I get my Subversion commits associated with the JIRA issues they belong
to? I've tried a couple of approaches, notably prepending the commit message
with "[LOG4J2-xxx]," but it doesn't seem to show up on the JIRA. Is there
something else I need to do? Does my Subversion user need to be so
[
https://issues.apache.org/jira/browse/LOG4J2-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LOG4J2-312.
-
Resolution: Fixed
{noformat}
commit -m "[LOG4J2-312] XML layout improvements (compact vs. pretty,
[
https://issues.apache.org/jira/browse/LOG4J2-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-160:
Fix Version/s: (was: 2.0-beta8)
2.0-beta9
> Include option in throwable
[
https://issues.apache.org/jira/browse/LOG4J2-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-159:
Fix Version/s: (was: 2.0-beta8)
2.0-beta9
> log4j.xml loading from class
Gary Gregory created LOG4J2-312:
---
Summary: XML layout improvements (compact vs. pretty, namespace,
namespace prefix, root element).
Key: LOG4J2-312
URL: https://issues.apache.org/jira/browse/LOG4J2-312
Great, thank you for the update.
Gary
On Wed, Jul 17, 2013 at 10:18 AM, Nick Williams <
[email protected]> wrote:
> Yes. As soon as I commit the new Log4j2Logger to JBoss Logging, I'm
> switching to Log4j to clean up my appenders/managers and look for any other
> appenders/managers
Yes. As soon as I commit the new Log4j2Logger to JBoss Logging, I'm switching
to Log4j to clean up my appenders/managers and look for any other
appenders/managers that suppress exceptions that prevent messages from being
logged.
Nick
On Jul 17, 2013, at 8:26 AM, Gary Gregory wrote:
> Nick,
>
[
https://issues.apache.org/jira/browse/LOG4J2-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Bindseil closed LOG4J2-302.
-
I verified the fix with beta8 - now it works. Thank you.
> NDCPatternConvert
[
https://issues.apache.org/jira/browse/LOG4J2-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Bindseil closed LOG4J2-302.
-
I verified the fix with beta8 - now it works. Thank you.
> NDCPatternConvert
Nick,
Will you be making these changes?
Gary
On Tue, Jul 16, 2013 at 12:39 PM, Ralph Goers wrote:
> As a general rule exceptions in appenders that cause the log event to fail
> to be written should be percolated. AppenderControl has the ability to
> suppress them if that is what the user want
Stopping the Appender is not going to cause a rollover. You need a rollover
policy that you can call that will then return true the next time it is
accessed. You then have to log between 1-16 events as the policy is only
checked every 16 events. Eliminating the need to have events be logged to c
[
https://issues.apache.org/jira/browse/LOG4J2-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-311:
---
Description:
FastFileManager#flush method needs to be synchronized.
I'm seeing the exception below.
Remko Popma created LOG4J2-311:
--
Summary: FastFileAppender and FastRollingFileAppender not
thread-safe
Key: LOG4J2-311
URL: https://issues.apache.org/jira/browse/LOG4J2-311
Project: Log4j 2
Iss
87 matches
Mail list logo
