Re: Logging the Java version

I think I misunderstood you. Yes, you can get java.vm.version and the like as system properties but they may not be completely formatted as Gary wishes. On Sep 18, 2014, at 4:38 PM, Ralph Goers wrote: > It isn't a system property > > Sent from my iPad > > On Sep 18, 2014, at 2:41 PM, Matt Si

Re: git commit: Refactor MAC address getter to own method.

What was the reason for pulling it out of UUIDUtil in the first place? Is it going to be used somewhere else? Ralph On Sep 18, 2014, at 7:08 PM, Remko Popma wrote: > If you anticipate using it in more places in this package, otherwise my > preference would be to make it private, and increase

Re: git commit: Refactor MAC address getter to own method.

If you anticipate using it in more places in this package, otherwise my preference would be to make it private, and increase the visibility when a new use case comes up. Sent from my iPhone > On 2014/09/19, at 10:51, Matt Sicker wrote: > > Package-private perhaps? > >> On 18 September 2014

Re: git commit: Refactor MAC address getter to own method.

Package-private perhaps? On 18 September 2014 20:01, Remko Popma wrote: > On an enterprise machine it is not uncommon to have multiple network > interface cards. When used internally in UUID, it is okay to ignore that > scenario, and it's also more convenient to return localhost rather than > nu

Re: git commit: Refactor MAC address getter to own method.

On an enterprise machine it is not uncommon to have multiple network interface cards. When used internally in UUID, it is okay to ignore that scenario, and it's also more convenient to return localhost rather than null if there is no network card at all. If we make this logic public, we cannot

Re: [1/4] git commit: Update JUL bridge docs.

Good catch. I'll push an update in a sec. On 18 September 2014 18:50, Remko Popma wrote: > Thanks! > > I just realized that if a JUL custom level is used without specifying a > LevelConverter, it's actually not a problem: the Logger's level will be > null and it will just use the log level of it

Re: [1/4] git commit: Update JUL bridge docs.

Thanks! I just realized that if a JUL custom level is used without specifying a LevelConverter, it's actually not a problem: the Logger's level will be null and it will just use the log level of its parent (that's a fairly recent change, I think)! Is it worth mentioning that in the docs? Sent

Re: [poll] Memory Mapped Appender in 2.1 vs 2.2?

You the man! Very nice! Sent from my iPhone > On 2014/09/19, at 7:47, Matt Sicker wrote: > > Updated the JUL component page docs, and added component docs for IOStreams. > >> On 18 September 2014 12:45, Remko Popma wrote: >> Note that JUL and IO Streams are not 100% done: >> The JUL component

Re: Logging the Java version

It isn't a system property Sent from my iPad > On Sep 18, 2014, at 2:41 PM, Matt Sicker wrote: > > Wouldn't this all be available through the ${sys:*} lookup variables? > >> On 18 September 2014 12:56, Ralph Goers wrote: >> I would recommend adding it as a special Lookup just like hostname is

Re: Looking for feedback LOG4J2-819

I'm thinking each LoggerContext can contain a sort of daemon thread for our various daemon threads that may be spawned. Use of the ThreadFactory interface like in the async package would be a better idea than calling new Thread(). More importantly, it would be useful to have an ExecutorService to k

Re: Optional Maven dependencies

Scratch that idea; it's damn near impossible to find anything about doclets anymore thanks to Oracle breaking every website they've taken over. So many dead links! On 17 September 2014 10:48, Matt Sicker wrote: > This reminds me of an idea I had lately. A custom Doclet (I think that's > what it'

Re: Docs & changelog entry for IO Streams module

Thanks for the JIRA ticket. Closed the issue and added it to the changelog (not in that order). On 16 September 2014 18:08, Remko Popma wrote: > I see, thanks! Perhaps the changelog entry could point to LOG4J2-547 > . > (481 was already included

[jira] [Closed] (LOG4J2-547) Update LoggerStream API

[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker closed LOG4J2-547. -- > Update LoggerStream API > --- > > Key: LOG4J2-547 > UR

[jira] [Resolved] (LOG4J2-547) Update LoggerStream API

[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker resolved LOG4J2-547. Resolution: Fixed Assignee: Matt Sicker (was: Ralph Goers) Implemented in 2.1. > Update Logg

Re: [poll] Memory Mapped Appender in 2.1 vs 2.2?

Updated the JUL component page docs, and added component docs for IOStreams. On 18 September 2014 12:45, Remko Popma wrote: > Note that JUL and IO Streams are not 100% done: > The JUL component page needs to be updated, > and the IO Streams component does not have a page yet. IOStreams also does

Re: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual page

Thanks for the clarification. I thought I knew that, but apparently I didn't. Still learning... Next step: deleting branch LOG4J2-431. (It's not easy from EGit, I got that far...) Sent from my iPhone > On 2014/09/19, at 6:49, Matt Sicker wrote: > > You should on rebase to the branch point tha

Re: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual page

You should on rebase to the branch point that you may have that hasn't been pushed anywhere. So for instance, if you have your own local branch and never push it, it works just fine to keep doing rebase. However, if you push out your branch like I've done a few times so far, then you need to merge

Re: Logging the Java version

Wouldn't this all be available through the ${sys:*} lookup variables? On 18 September 2014 12:56, Ralph Goers wrote: > I would recommend adding it as a special Lookup just like hostname is. > Then in your pattern layout you just need to specify the header as > ${java-version} or ${java-short-ve

Re: Logging the Java version

I would recommend adding it as a special Lookup just like hostname is. Then in your pattern layout you just need to specify the header as ${java-version} or ${java-short-version}, etc. Ralph On Sep 18, 2014, at 9:51 AM, Gary Gregory wrote: > > I would like the start of my logs to start with

Re: [poll] Memory Mapped Appender in 2.1 vs 2.2?

Note that JUL and IO Streams are not 100% done: The JUL component page needs to be updated, and the IO Streams component does not have a page yet. IOStreams also does not have a changelog entry yet. (Is LOG4J2-547 the correct Jira for IO Streams? G

[jira] [Updated] (LOG4J2-829) Error replace slash in pattern file when rolling file appender

[ https://issues.apache.org/jira/browse/LOG4J2-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-829: --- Description: With following log configuration {code} %d %p %c{1.} [%t] %m%n

[jira] [Updated] (LOG4J2-506) Binary logging interface

[ https://issues.apache.org/jira/browse/LOG4J2-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-506: --- Labels: binary (was: ) > Binary logging interface > > > Key:

[jira] [Created] (LOG4J2-837) Hex-dump layout for binary messages

Remko Popma created LOG4J2-837: -- Summary: Hex-dump layout for binary messages Key: LOG4J2-837 URL: https://issues.apache.org/jira/browse/LOG4J2-837 Project: Log4j 2 Issue Type: New Feature

Re: [poll] Memory Mapped Appender in 2.1 vs 2.2?

I'd rather RERO and keep moving. But the timiing depends on Matt's availability to RM a beta and/or release candidate. I think the path we agreed on is to cut a beta ASAP to put the new features (JUL, IO streams, and now MMFA) in the wild. I'd like to think we are fixing bug or addressing reports

Re: [poll] Memory Mapped Appender in 2.1 vs 2.2?

All interesting stuff! Are we targeting this for 2.1? On Fri, Sep 19, 2014 at 1:41 AM, Gary Gregory wrote: > Next I'd like to see something to help log hex dumps. I emailed about this > in the last couple of weeks. > > I would also like the start of my logs to start with the same information > "

[jira] [Resolved] (LOG4J2-431) Create MemoryMappedFileAppender

[ https://issues.apache.org/jira/browse/LOG4J2-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma resolved LOG4J2-431. Resolution: Fixed Merged into master in b1783a0aa3174fce0605a806522e9480a33e26d9. > Create MemoryMa

[jira] [Closed] (LOG4J2-431) Create MemoryMappedFileAppender

[ https://issues.apache.org/jira/browse/LOG4J2-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed LOG4J2-431. -- > Create MemoryMappedFileAppender > --- > > Key: LOG4J2-431 >

Logging the Java version

I would like the start of my logs to start with the same information "java -version" provides. On the console, "java -version" says: java version "1.8.0_20" Java(TM) SE Runtime Environment (build 1.8.0_20-b26) Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode) I cook this up manuall

Re: [poll] Memory Mapped Appender in 2.1 vs 2.2?

Next I'd like to see something to help log hex dumps. I emailed about this in the last couple of weeks. I would also like the start of my logs to start with the same information "java -version" provides.Separate message coming. Gary On Thu, Sep 18, 2014 at 12:22 PM, Remko Popma wrote: > Well,

Re: [poll] Memory Mapped Appender in 2.1 vs 2.2?

Well, sure, after documenting this appender and testing it on 4 OS'es and 8 JVMs I think it is ready to be merged and included in 2.1. It doesn't get much more polished than that... :-) I don't see any reason not to include it so I'll go ahead and merge LOG4J2-431 into master. About polishing and

[jira] [Commented] (LOG4J2-836) Binary Logging Appender

[ https://issues.apache.org/jira/browse/LOG4J2-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14139004#comment-14139004 ] Ralph Goers commented on LOG4J2-836: Log4j 2 has some "receivers" for sockets, JMS and

[jira] [Commented] (LOG4J2-836) Binary Logging Appender

[ https://issues.apache.org/jira/browse/LOG4J2-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14139003#comment-14139003 ] Abhishek Sharma commented on LOG4J2-836: Thanks [[email protected]] for

[jira] [Commented] (LOG4J2-836) Binary Logging Appender

[ https://issues.apache.org/jira/browse/LOG4J2-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14138997#comment-14138997 ] Ralph Goers commented on LOG4J2-836: One of the reasons Log4j 2 uses OutputStreams ins

[jira] [Commented] (LOG4J2-836) Binary Logging Appender

[ https://issues.apache.org/jira/browse/LOG4J2-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14138934#comment-14138934 ] Remko Popma commented on LOG4J2-836: Thank you for your interest in log4j2. Binary log

Re: [poll] Memory Mapped Appender in 2.1 vs 2.2?

It's just a poll, we have to draw the line somewhere and polish and address Jiras for 2.1. I know we operate in what feels sometimes like a free-for-all but it seems appropriate to slow things down a bit before we think of releasing. We also operate in a "do-ocracy" so I do not think any one will s

[jira] [Created] (LOG4J2-836) Binary Logging Appender

Abhishek Sharma created LOG4J2-836: -- Summary: Binary Logging Appender Key: LOG4J2-836 URL: https://issues.apache.org/jira/browse/LOG4J2-836 Project: Log4j 2 Issue Type: Wish Compon

Re: [poll] Memory Mapped Appender in 2.1 vs 2.2?

The code, tests and docs are ready and I was about to merge the LOG4J2-431 branch into master. Why are we having a poll about this appender? What makes it different from, say, GELFLayout? On Thu, Sep 18, 2014 at 8:47 PM, Gary Gregory wrote: > Any thoughts on merging the MMA for 2.1 vs. 2.2? > >

[poll] Memory Mapped Appender in 2.1 vs 2.2?

Any thoughts on merging the MMA for 2.1 vs. 2.2? Gary -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action

[jira] [Closed] (LOG4J2-835) Possibility to turn off logging of lib name and version in exception stack trace

[ https://issues.apache.org/jira/browse/LOG4J2-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Korenkov closed LOG4J2-835. - Resolution: Not a Problem > Possibility to turn off logging of lib name and version in exception s

[jira] [Commented] (LOG4J2-835) Possibility to turn off logging of lib name and version in exception stack trace

[ https://issues.apache.org/jira/browse/LOG4J2-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14138663#comment-14138663 ] Anton Korenkov commented on LOG4J2-835: --- Thanks a lot! I was confused that in log4j