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

See

Re: [GitHub] logging-log4j2 issue #82: Add a new LuceneAppender which writes logging even...

I think that would be too expensive to do on each event. Note that there are three levels: addDocument(), flush(), and commit(). I could see that how often to flush and or commit should be configurable. Either every N events, or every N TimeUnits. Gary On Mon, Jul 24, 2017 at 9:04 PM, kenneth mc

Re: Type Erasure

YW :-) Gary On Mon, Jul 24, 2017 at 8:40 PM, kenneth mcfarland < kennethpmcfarl...@gmail.com> wrote: > That's really cool and I apologize for being ignorant. I did Google > afterwards, it reminds me of the first time I saw a ternary. Thanks for the > explanation. > > 👍 > > On Jul 24, 2017 8:25 P

Re: [GitHub] logging-log4j2 issue #82: Add a new LuceneAppender which writes logging even...

Ok I'm blind but maybe can add a commit() after line 193 right after addDocument() to be aggressive On Jul 24, 2017 8:54 PM, "garydgregory" wrote: > Github user garydgregory commented on the issue: > > https://github.com/apache/logging-log4j2/pull/82 > > Is what is happening > in org

[GitHub] logging-log4j2 issue #82: Add a new LuceneAppender which writes logging even...

Github user garydgregory commented on the issue: https://github.com/apache/logging-log4j2/pull/82 Is what is happening in org.apache.logging.log4j.lucene5.appender.LuceneAppender.stop(long, TimeUnit) not good enough? Gary On Mon, Jul 24, 2017 at 8:30 PM, asfbot

Re: Type Erasure

That's really cool and I apologize for being ignorant. I did Google afterwards, it reminds me of the first time I saw a ternary. Thanks for the explanation. 👍 On Jul 24, 2017 8:25 PM, "Gary Gregory" wrote: > In Java 7, the Java compiler can use type inference to allow you to change > the verbos

Re: [GitHub] logging-log4j2 issue #82: Add a new LuceneAppender which writes logging even...

Forgive me, I just mean the close() method. On Mon, Jul 24, 2017 at 8:30 PM, kenneth mcfarland < kennethpmcfarl...@gmail.com> wrote: > Why don't you call close() or commit() on the indexwriter? If log4j2 is > serious about being an auditing platform some attention to flushing and > such should be

Re: [GitHub] logging-log4j2 issue #82: Add a new LuceneAppender which writes logging even...

Why don't you call close() or commit() on the indexwriter? If log4j2 is serious about being an auditing platform some attention to flushing and such should be addressed. Note I am not an expert but I believe I am somewhere in the ballpark. On Mon, Jul 24, 2017 at 8:27 PM, garydgregory wrote: > G

[GitHub] logging-log4j2 issue #82: Add a new LuceneAppender which writes logging even...

Github user garydgregory commented on the issue: https://github.com/apache/logging-log4j2/pull/82 Thank you for your submission @liyuj ! Can you try the "Lucene5" branch and confirm that it works for you? --- If your project is set up for it, you can reply to this email and have your

Re: Type Erasure

In Java 7, the Java compiler can use type inference to allow you to change the verbose: List list = new ArrayList(); into the less verbose: List list = new ArrayList<>(); Since you are assigning to a List, the only type you can possibly use in an ArrayList<> is a String, so you can omit it. Ga

[GitHub] logging-log4j2 issue #82: Add a new LuceneAppender which writes logging even...

Github user liyuj commented on the issue: https://github.com/apache/logging-log4j2/pull/82 https://www.zybuluo.com/liyuj/note/825932 I wrote a document. Can the community help me check? --- If your project is set up for it, you can reply to this email and have your reply appear on

Re: [log4cxx] Release process releated questions

On Sun, Jul 23, 2017 at 11:37 AM, Thorsten Schöning wrote: > Guten Tag Robert Middleton, > am Samstag, 22. Juli 2017 um 23:44 schrieben Sie: > >> I tried to verify with: gpg --verify apache-log4cxx-0.11.0.tar.gz.asc >> apache-log4cxx-0.11.0.tar.gz >> but gpg couldn't find the public key - do I nee

Type Erasure

I have a simple question as why there is generic arrays like new ArrayList<>(); in classes like: log4j-core/src.../core/builder/impl/DefaultComponentBuilder(); Note, this is not a "why didn't you do it differently" question, I am asking so I can learn from you. Thx. Kenneth

Re: logging-log4j2 git commit: LOG4J2-1986 Public API for parsing the output from JsonLayout/XmlLayout/YamlLayout into a LogEvent

rethrow(e) doesn't wrap the exception, so there's no useless exception. On 24 July 2017 at 15:34, Mikael Ståldal wrote: > I could use "Throwables.rethrow(e)", but is that really better than "throw > new RuntimeException(e)"? > > > > On 2017-07-24 22:06, Matt Sicker wrote: > >> Java 8 added an Un

Re: logging-log4j2 git commit: LOG4J2-1986 Public API for parsing the output from JsonLayout/XmlLayout/YamlLayout into a LogEvent

Hi All, I see two paths: (1) All these APIs (if they are indeed needed, are they?) could throw both IOException and ParseException (assuming you want to keep ParseException a direct subclass of ParseException). My reasoning here is that the underlying code like a Jackson Object Mapper may have a

Re: logging-log4j2 git commit: LOG4J2-1986 Public API for parsing the output from JsonLayout/XmlLayout/YamlLayout into a LogEvent

On Mon, Jul 24, 2017 at 1:31 PM, Mikael Ståldal wrote: > The code you posted will never throw ParseException. > It sure does! See: @Override public LogEvent parseFrom(byte[] input) throws ParseException { try { return objectReader.readValue(input); } catch (I

Re: logging-log4j2 git commit: LOG4J2-1986 Public API for parsing the output from JsonLayout/XmlLayout/YamlLayout into a LogEvent

I could use "Throwables.rethrow(e)", but is that really better than "throw new RuntimeException(e)"? On 2017-07-24 22:06, Matt Sicker wrote: Java 8 added an UncheckedIOException class which is handy for rethrowing IOException. Since we're on 7, that class isn't available. However, if you just

Re: logging-log4j2 git commit: LOG4J2-1986 Public API for parsing the output from JsonLayout/XmlLayout/YamlLayout into a LogEvent

The code you posted will never throw ParseException. Yes, ParseException could extend IOException, but I would still have to do translation. On 2017-07-24 22:20, Gary Gregory wrote: Wht? Note that the code I posted here compiles just fine. A JsonProcessingException is already a subclas

[GitHub] logging-log4j2 pull request #98: Remove a large number of empty comments in ...

Github user asfgit closed the pull request at: https://github.com/apache/logging-log4j2/pull/98 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature

Re: logging-log4j2 git commit: LOG4J2-1986 Public API for parsing the output from JsonLayout/XmlLayout/YamlLayout into a LogEvent

Wht? Note that the code I posted here compiles just fine. A JsonProcessingException is already a subclass of IOException. Wrapping JsonProcessingException in a ParseException is just adding a level of indirection for which I see no point, especially when the methods already throw IOException.

[GitHub] logging-log4j2 pull request #98: Remove a large number of empty comments in ...

GitHub user kpm1985 opened a pull request: https://github.com/apache/logging-log4j2/pull/98 Remove a large number of empty comments in Generate.java You can merge this pull request into a Git repository by running: $ git pull https://github.com/kpm1985/logging-log4j2 cleanup

Re: logging-log4j2 git commit: LOG4J2-1986 Public API for parsing the output from JsonLayout/XmlLayout/YamlLayout into a LogEvent

Java 8 added an UncheckedIOException class which is handy for rethrowing IOException. Since we're on 7, that class isn't available. However, if you just want to throw it, you can use the rethrow() method in Throwables which won't wrap the exception (abuses type erasure to allow checked exceptions t

Re: logging-log4j2 git commit: LOG4J2-1986 Public API for parsing the output from JsonLayout/XmlLayout/YamlLayout into a LogEvent

But that won't work, I need to at least translate JsonProcessingException (Jackson specific, which we don't want to expose) to our own ParseException. On 2017-07-23 22:01, Gary Gregory wrote: @Override public LogEvent parseFrom(InputStream input) throws IOException, ParseException {

Re: logging-log4j2 git commit: LOG4J2-1986 Public API for parsing the output from JsonLayout/XmlLayout/YamlLayout into a LogEvent

But what would that be? I think that java.io.IOException is fine when unable to read from underlaying input. But that shouldn't happen when reading from String or byte[], should it? I don't feel like defining "BogusIOException". On 2017-07-24 05:28, Matt Sicker wrote: But some of the methods

Jenkins build became unstable: Log4j 2.x #2928

See

Re: logging-log4j2 git commit: LOG4J2-1986 Public API for parsing the output from JsonLayout/XmlLayout/YamlLayout into a LogEvent

Yes, I'll do that. On 2017-07-23 23:46, Gary Gregory wrote: Also, I'd like to see this used from our socket server classes to make sure it fits nicely with that use case. Gary On Sun, Jul 23, 2017 at 1:05 PM, Gary Gregory wrote: OK, but RuntimeException should still never be thrown here...

[jira] [Comment Edited] (LOG4J2-1987) Log4J JUL Bridge and RMI Security Manager causes access denied ("java.util.logging.LoggingPermission" "control")

[ https://issues.apache.org/jira/browse/LOG4J2-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16098924#comment-16098924 ] Gary Gregory edited comment on LOG4J2-1987 at 7/24/17 6:11 PM:

[jira] [Comment Edited] (LOG4J2-1987) Log4J JUL Bridge and RMI Security Manager causes access denied ("java.util.logging.LoggingPermission" "control")

[ https://issues.apache.org/jira/browse/LOG4J2-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16098924#comment-16098924 ] Gary Gregory edited comment on LOG4J2-1987 at 7/24/17 6:11 PM:

[jira] [Resolved] (LOG4J2-1987) Log4J JUL Bridge and RMI Security Manager causes access denied ("java.util.logging.LoggingPermission" "control")

[ https://issues.apache.org/jira/browse/LOG4J2-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved LOG4J2-1987. -- Resolution: Fixed Fix Version/s: 2.9 I fixed the one call site but there could be many o

[jira] [Commented] (LOG4J2-1987) Log4J JUL Bridge and RMI Security Manager causes access denied ("java.util.logging.LoggingPermission" "control")

[ https://issues.apache.org/jira/browse/LOG4J2-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16098920#comment-16098920 ] ASF subversion and git services commented on LOG4J2-1987: - Commit

[jira] [Updated] (LOG4J2-1987) Log4J JUL Bridge and RMI Security Manager causes access denied ("java.util.logging.LoggingPermission" "control")

[ https://issues.apache.org/jira/browse/LOG4J2-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOG4J2-1987: - Summary: Log4J JUL Bridge and RMI Security Manager causes access denied ("java.util.logging.Loggi

Re: [VOTE] Release Log4j Scala API version 11.0 RC2

I've committed the artifacts to svn < https://dist.apache.org/repos/dist/release/logging/log4j/scala/11.0/> and released the staging repo to Maven Central (minus the samples and dist artifacts). I also updated reporter.apache.org. What remains now is to wait a bit for mirrors to catch up, then we c

Re: [VOTE] Release Log4j Scala API version 11.0 RC2

+1 from me. This vote passes with 3 +1 votes from myself, Gary, and Mikael. I'll continue with the release. On 23 July 2017 at 21:10, Matt Sicker wrote: > Away from computer at the moment, but yes, I'll be taking care of this as > soon as possible. > > On 23 July 2017 at 18:54, Gary Gregory wr

[jira] [Commented] (LOG4J2-1961) Reconfigure breaks DirectWriteRolloverStrategy

[ https://issues.apache.org/jira/browse/LOG4J2-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16098256#comment-16098256 ] Christian Vent commented on LOG4J2-1961: [~mikaelstaldal] I'm using Java 8 in my

[jira] [Created] (LOG4J2-1987) Log4J JUL Bridge seems to be not working with RMI Security Manager

Andreas Felder created LOG4J2-1987: -- Summary: Log4J JUL Bridge seems to be not working with RMI Security Manager Key: LOG4J2-1987 URL: https://issues.apache.org/jira/browse/LOG4J2-1987 Project: Log4j