Re: Planning out what we can do to get Chainsaw back in the game

[Matt Sicker]

Using Kotlin could also attract Android developers who were otherwise stuck
using Java 6 for years.

As mentioned in an earlier reply, this framework could be useful for
Kotlin/JavaFX: 

On 10 November 2017 at 22:12, Remko Popma  wrote:

> Now that I think of it, all else being equal, the combination of Kotlin
> and JavaFX may be attractive to get other new developers interested and
> grow the community...
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
> > On Nov 11, 2017, at 10:58, Matt Sicker  wrote:
> >
> > Considering it takes about 2-3 months of daily use of Scala to get
> > comfortable, perhaps Kotlin would be a better choice. It's a simpler
> > language and is supposed to be easy for Java developers to pick up.
> >
> >> On 10 November 2017 at 19:43, Remko Popma 
> wrote:
> >>
> >> I don’t know either language but I’d be more interested in learning
> Kotlin
> >> than learning Scala.
> >>
> >> OTOH I’m not sure how much time I’ll be able to contribute to Chainsaw
> so
> >> not sure how much that should count for.
> >>
> >> (Shameless plug) Every java main() method deserves http://picocli.info
> >>
> >>> On Nov 11, 2017, at 10:16, Matt Sicker  wrote:
> >>>
> >>> That's what I hear. I don't know Kotlin, but I'd certainly be
> interested
> >> in
> >>> learning! (particularly so I can write Gradle builds in a statically
> >> typed
> >>> language)
> >>>
>  On 10 November 2017 at 19:10, Gary Gregory 
> >> wrote:
> 
>  I think Kotlin would be more approachable than Scala... thoughts?
> 
>  Gary
> 
> > On Fri, Nov 10, 2017 at 3:26 PM, Matt Sicker 
> wrote:
> >
> > On 10 November 2017 at 16:17, Robert Middleton 
> > wrote:
> >
> >> What would the advantage be of using Scala vs just normal Java?
> >> Mostly from a curiosity standpoint; I've never done Scala so I don't
> >> know it works.
> >>
> >
> > The main advantage I can see is that most of the developers
> interested
> >> in
> > working on v3 all prefer to work in Scala. I could go on and on about
>  Scala
> > over Java, but really, my comparison would all come down to
> functional
> > programming over object oriented programming. When it comes to shared
> > libraries like Log4j, I find Java far more appropriate and work in
> that
> > space. In a GUI application where there is no real public API? I'd
> >> rather
> > work in Scala. Kotlin was another option, but it seems like none of
> us
> > really have experience there.
> >
> >
> >> Did you actually have trouble building?  I'm pretty sure that when I
> >> built it a few months ago I simply opened up the project in Netbeans
> >> and it built immediately as a maven project(although looking at the
> >> POM it does look like it uses ant on the backend for some reason).
> >>
> >
> > Building the project is simple enough. I had issues with:
> >
> > 1. Running mvn clean install does not work by default unless you run
> >> "mvn
> > site:site" before running "mvn install".
> > 2. Doesn't build in Java 9.
> > 3. The maven-release-plugin is not configured at all, so I had to do
> >> all
> > release steps by hand instead.
> >
> > --
> > Matt Sicker 
> >
> 
> >>>
> >>>
> >>>
> >>> --
> >>> Matt Sicker 
> >>
> >
> >
> >
> > --
> > Matt Sicker 
>



-- 
Matt Sicker 

Re: Planning out what we can do to get Chainsaw back in the game

[Remko Popma]

Now that I think of it, all else being equal, the combination of Kotlin and 
JavaFX may be attractive to get other new developers interested and grow the 
community...

(Shameless plug) Every java main() method deserves http://picocli.info

> On Nov 11, 2017, at 10:58, Matt Sicker  wrote:
> 
> Considering it takes about 2-3 months of daily use of Scala to get
> comfortable, perhaps Kotlin would be a better choice. It's a simpler
> language and is supposed to be easy for Java developers to pick up.
> 
>> On 10 November 2017 at 19:43, Remko Popma  wrote:
>> 
>> I don’t know either language but I’d be more interested in learning Kotlin
>> than learning Scala.
>> 
>> OTOH I’m not sure how much time I’ll be able to contribute to Chainsaw so
>> not sure how much that should count for.
>> 
>> (Shameless plug) Every java main() method deserves http://picocli.info
>> 
>>> On Nov 11, 2017, at 10:16, Matt Sicker  wrote:
>>> 
>>> That's what I hear. I don't know Kotlin, but I'd certainly be interested
>> in
>>> learning! (particularly so I can write Gradle builds in a statically
>> typed
>>> language)
>>> 
 On 10 November 2017 at 19:10, Gary Gregory 
>> wrote:
 
 I think Kotlin would be more approachable than Scala... thoughts?
 
 Gary
 
> On Fri, Nov 10, 2017 at 3:26 PM, Matt Sicker  wrote:
> 
> On 10 November 2017 at 16:17, Robert Middleton 
> wrote:
> 
>> What would the advantage be of using Scala vs just normal Java?
>> Mostly from a curiosity standpoint; I've never done Scala so I don't
>> know it works.
>> 
> 
> The main advantage I can see is that most of the developers interested
>> in
> working on v3 all prefer to work in Scala. I could go on and on about
 Scala
> over Java, but really, my comparison would all come down to functional
> programming over object oriented programming. When it comes to shared
> libraries like Log4j, I find Java far more appropriate and work in that
> space. In a GUI application where there is no real public API? I'd
>> rather
> work in Scala. Kotlin was another option, but it seems like none of us
> really have experience there.
> 
> 
>> Did you actually have trouble building?  I'm pretty sure that when I
>> built it a few months ago I simply opened up the project in Netbeans
>> and it built immediately as a maven project(although looking at the
>> POM it does look like it uses ant on the backend for some reason).
>> 
> 
> Building the project is simple enough. I had issues with:
> 
> 1. Running mvn clean install does not work by default unless you run
>> "mvn
> site:site" before running "mvn install".
> 2. Doesn't build in Java 9.
> 3. The maven-release-plugin is not configured at all, so I had to do
>> all
> release steps by hand instead.
> 
> --
> Matt Sicker 
> 
 
>>> 
>>> 
>>> 
>>> --
>>> Matt Sicker 
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: logging-log4j2 git commit: [LOG4J2-2114] Provide a native Log4j 2 implementation of Eclipse Jetty's org.eclipse.jetty.util.log.Logger.

[Matt Sicker]

Wouldn't this implementation contain incorrect caller location information?

On 10 November 2017 at 19:25,  wrote:

> Repository: logging-log4j2
> Updated Branches:
>   refs/heads/master aad2f132b -> 7d52f131e
>
>
> [LOG4J2-2114] Provide a native Log4j 2 implementation of Eclipse Jetty's
> org.eclipse.jetty.util.log.Logger.
>
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
> commit/7d52f131
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/7d52f131
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/7d52f131
>
> Branch: refs/heads/master
> Commit: 7d52f131ec1e000834bcb40343f3f2d41805c75a
> Parents: aad2f13
> Author: Gary Gregory 
> Authored: Fri Nov 10 18:25:47 2017 -0700
> Committer: Gary Gregory 
> Committed: Fri Nov 10 18:25:47 2017 -0700
>
> --
>  log4j-appserver/pom.xml |   8 +
>  .../log4j/appserver/jetty/Log4j2Logger.java | 184 +++
>  src/changes/changes.xml |   3 +
>  3 files changed, 195 insertions(+)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> 7d52f131/log4j-appserver/pom.xml
> --
> diff --git a/log4j-appserver/pom.xml b/log4j-appserver/pom.xml
> index e96b1fc..6acd77b 100644
> --- a/log4j-appserver/pom.xml
> +++ b/log4j-appserver/pom.xml
> @@ -34,6 +34,7 @@
>  Web Documentation
>  /log4j-appserver
>  8.5.20
> +8.2.0.v20160908 
>  org.apache.logging.log4j.appserver
>
>
> @@ -56,6 +57,7 @@
>org.apache.tomcat
>tomcat-catalina
>${tomcat.version}
> +  provided
>
>  
>org.apache.tomcat
> @@ -71,6 +73,12 @@
>  
>
>  
> +
> +  org.eclipse.jetty
> +  jetty-util
> +  ${jetty.version}
> +  provided
> +
>
>  
>  
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> 7d52f131/log4j-appserver/src/main/java/org/apache/logging/
> log4j/appserver/jetty/Log4j2Logger.java
> --
> diff --git a/log4j-appserver/src/main/java/org/apache/logging/log4j/
> appserver/jetty/Log4j2Logger.java b/log4j-appserver/src/main/
> java/org/apache/logging/log4j/appserver/jetty/Log4j2Logger.java
> new file mode 100644
> index 000..7d1ce14
> --- /dev/null
> +++ b/log4j-appserver/src/main/java/org/apache/logging/log4j/
> appserver/jetty/Log4j2Logger.java
> @@ -0,0 +1,184 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache license, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License. You may obtain a copy of the License at
> + *
> + *  http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> + * See the license for the specific language governing permissions and
> + * limitations under the license.
> + */
> +
> +package org.apache.logging.log4j.appserver.jetty;
> +
> +import org.apache.logging.log4j.LogManager;
> +import org.eclipse.jetty.util.log.AbstractLogger;
> +import org.eclipse.jetty.util.log.Logger;
> +
> +/**
> + * Provides a native Apache Log4j 2 for Jetty logging.
> + */
> +public class Log4j2Logger extends AbstractLogger {
> +
> +private final org.apache.logging.log4j.Logger logger;
> +
> +private final String name;
> +
> +public Log4j2Logger(final String name) {
> +super();
> +this.name = name;
> +this.logger = LogManager.getLogger(name);
> +}
> +
> +public Log4j2Logger() {
> +this("");
> +}
> +
> +/*
> + * (non-Javadoc)
> + *
> + * @see org.eclipse.jetty.util.log.Logger#debug(java.lang.String,
> java.lang.Object[])
> + */
> +@Override
> +public void debug(final String msg, final Object... args) {
> +logger.debug(msg, args);
> +}
> +
> +/*
> + * (non-Javadoc)
> + *
> + * @see org.eclipse.jetty.util.log.Logger#debug(java.lang.String,
> java.lang.Throwable)
> + */
> +@Override
> +public void debug(final String msg, final Throwable thrown) {
> +logger.debug(msg, thrown);
> +}
> +
> +/*
> + * (non-Javadoc)
> + *
> + * @see org.eclipse.jetty.util.log.Logger#debug(java.lang.Throwable)
> + 

Re: Planning out what we can do to get Chainsaw back in the game

[Matt Sicker]

Considering it takes about 2-3 months of daily use of Scala to get
comfortable, perhaps Kotlin would be a better choice. It's a simpler
language and is supposed to be easy for Java developers to pick up.

On 10 November 2017 at 19:43, Remko Popma  wrote:

> I don’t know either language but I’d be more interested in learning Kotlin
> than learning Scala.
>
> OTOH I’m not sure how much time I’ll be able to contribute to Chainsaw so
> not sure how much that should count for.
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
> > On Nov 11, 2017, at 10:16, Matt Sicker  wrote:
> >
> > That's what I hear. I don't know Kotlin, but I'd certainly be interested
> in
> > learning! (particularly so I can write Gradle builds in a statically
> typed
> > language)
> >
> >> On 10 November 2017 at 19:10, Gary Gregory 
> wrote:
> >>
> >> I think Kotlin would be more approachable than Scala... thoughts?
> >>
> >> Gary
> >>
> >>> On Fri, Nov 10, 2017 at 3:26 PM, Matt Sicker  wrote:
> >>>
> >>> On 10 November 2017 at 16:17, Robert Middleton 
> >>> wrote:
> >>>
>  What would the advantage be of using Scala vs just normal Java?
>  Mostly from a curiosity standpoint; I've never done Scala so I don't
>  know it works.
> 
> >>>
> >>> The main advantage I can see is that most of the developers interested
> in
> >>> working on v3 all prefer to work in Scala. I could go on and on about
> >> Scala
> >>> over Java, but really, my comparison would all come down to functional
> >>> programming over object oriented programming. When it comes to shared
> >>> libraries like Log4j, I find Java far more appropriate and work in that
> >>> space. In a GUI application where there is no real public API? I'd
> rather
> >>> work in Scala. Kotlin was another option, but it seems like none of us
> >>> really have experience there.
> >>>
> >>>
>  Did you actually have trouble building?  I'm pretty sure that when I
>  built it a few months ago I simply opened up the project in Netbeans
>  and it built immediately as a maven project(although looking at the
>  POM it does look like it uses ant on the backend for some reason).
> 
> >>>
> >>> Building the project is simple enough. I had issues with:
> >>>
> >>> 1. Running mvn clean install does not work by default unless you run
> "mvn
> >>> site:site" before running "mvn install".
> >>> 2. Doesn't build in Java 9.
> >>> 3. The maven-release-plugin is not configured at all, so I had to do
> all
> >>> release steps by hand instead.
> >>>
> >>> --
> >>> Matt Sicker 
> >>>
> >>
> >
> >
> >
> > --
> > Matt Sicker 
>



-- 
Matt Sicker 

Re: Planning out what we can do to get Chainsaw back in the game

[Remko Popma]

I don’t know either language but I’d be more interested in learning Kotlin than 
learning Scala. 

OTOH I’m not sure how much time I’ll be able to contribute to Chainsaw so not 
sure how much that should count for. 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Nov 11, 2017, at 10:16, Matt Sicker  wrote:
> 
> That's what I hear. I don't know Kotlin, but I'd certainly be interested in
> learning! (particularly so I can write Gradle builds in a statically typed
> language)
> 
>> On 10 November 2017 at 19:10, Gary Gregory  wrote:
>> 
>> I think Kotlin would be more approachable than Scala... thoughts?
>> 
>> Gary
>> 
>>> On Fri, Nov 10, 2017 at 3:26 PM, Matt Sicker  wrote:
>>> 
>>> On 10 November 2017 at 16:17, Robert Middleton 
>>> wrote:
>>> 
 What would the advantage be of using Scala vs just normal Java?
 Mostly from a curiosity standpoint; I've never done Scala so I don't
 know it works.
 
>>> 
>>> The main advantage I can see is that most of the developers interested in
>>> working on v3 all prefer to work in Scala. I could go on and on about
>> Scala
>>> over Java, but really, my comparison would all come down to functional
>>> programming over object oriented programming. When it comes to shared
>>> libraries like Log4j, I find Java far more appropriate and work in that
>>> space. In a GUI application where there is no real public API? I'd rather
>>> work in Scala. Kotlin was another option, but it seems like none of us
>>> really have experience there.
>>> 
>>> 
 Did you actually have trouble building?  I'm pretty sure that when I
 built it a few months ago I simply opened up the project in Netbeans
 and it built immediately as a maven project(although looking at the
 POM it does look like it uses ant on the backend for some reason).
 
>>> 
>>> Building the project is simple enough. I had issues with:
>>> 
>>> 1. Running mvn clean install does not work by default unless you run "mvn
>>> site:site" before running "mvn install".
>>> 2. Doesn't build in Java 9.
>>> 3. The maven-release-plugin is not configured at all, so I had to do all
>>> release steps by hand instead.
>>> 
>>> --
>>> Matt Sicker 
>>> 
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: [PROPOSAL] New module log4j-jetty

[Gary Gregory]

On Thu, Nov 9, 2017 at 3:33 PM, Gary Gregory  wrote:

> On Thu, Nov 9, 2017 at 3:32 PM, Ralph Goers 
> wrote:
>
>>
>> > On Nov 9, 2017, at 2:34 PM, Gary Gregory 
>> wrote:
>> >
>> > On Thu, Nov 9, 2017 at 1:49 PM, Ralph Goers > >
>> > wrote:
>> >
>> >> Every module equates to another jar. I just don’t see why we need a jar
>> >> for one class where a jar with 2 (as well as classes for other app
>> servers)
>> >> will serve equally as well.
>> >>
>> >
>> > First, thank you for being patient here and continuing to entertain this
>> > idea :-) So much can get lost in emails.
>> >
>> > The case of app servers is a great one because these are usually huge
>> > complex beasts with sometimes lots of dependencies.
>> >
>> > I do not think we want to end up with a kitchen sink app server module.
>> > From a developer's experience POV, I would never want my tooling (like
>> > Maven) to end up downloading and configuring in a project jars from a
>> bunch
>> > of app servers and their dependencies. Especially since any single
>> > application will likely only use a single app server (like the one I am
>> > working on now, we are using Jetty and that's it.)
>> >
>> > Gary
>>
>> I don’t think this is ever going to happen. As a user, you will download
>> log4j-appserver as a dependency and everything else should be marked as
>> provided. If you are using Jetty then the tomcat stuff will just be ignored.
>>
>> Frankly I am expecting that there won’t be many classes per app server.
>> Typically, it is just what is needed to bind the app server’s logging to
>> log4j. It is possible we might have lookup’s specific to the platform, but
>> I would expect we would have an easy way to determine which ones are
>> appropriate and which aren’t.
>>
>
> OK, I'll tuck in the Jetty code in log4j-appserver.
>

Finally got around to it. Done.

Gary


>
> Gary
>
>
>>
>> Ralph
>>
>
>

Re: Planning out what we can do to get Chainsaw back in the game

[Matt Sicker]

That's what I hear. I don't know Kotlin, but I'd certainly be interested in
learning! (particularly so I can write Gradle builds in a statically typed
language)

On 10 November 2017 at 19:10, Gary Gregory  wrote:

> I think Kotlin would be more approachable than Scala... thoughts?
>
> Gary
>
> On Fri, Nov 10, 2017 at 3:26 PM, Matt Sicker  wrote:
>
> > On 10 November 2017 at 16:17, Robert Middleton 
> > wrote:
> >
> > > What would the advantage be of using Scala vs just normal Java?
> > > Mostly from a curiosity standpoint; I've never done Scala so I don't
> > > know it works.
> > >
> >
> > The main advantage I can see is that most of the developers interested in
> > working on v3 all prefer to work in Scala. I could go on and on about
> Scala
> > over Java, but really, my comparison would all come down to functional
> > programming over object oriented programming. When it comes to shared
> > libraries like Log4j, I find Java far more appropriate and work in that
> > space. In a GUI application where there is no real public API? I'd rather
> > work in Scala. Kotlin was another option, but it seems like none of us
> > really have experience there.
> >
> >
> > > Did you actually have trouble building?  I'm pretty sure that when I
> > > built it a few months ago I simply opened up the project in Netbeans
> > > and it built immediately as a maven project(although looking at the
> > > POM it does look like it uses ant on the backend for some reason).
> > >
> >
> > Building the project is simple enough. I had issues with:
> >
> > 1. Running mvn clean install does not work by default unless you run "mvn
> > site:site" before running "mvn install".
> > 2. Doesn't build in Java 9.
> > 3. The maven-release-plugin is not configured at all, so I had to do all
> > release steps by hand instead.
> >
> > --
> > Matt Sicker 
> >
>



-- 
Matt Sicker 

Re: Planning out what we can do to get Chainsaw back in the game

[Gary Gregory]

I think Kotlin would be more approachable than Scala... thoughts?

Gary

On Fri, Nov 10, 2017 at 3:26 PM, Matt Sicker  wrote:

> On 10 November 2017 at 16:17, Robert Middleton 
> wrote:
>
> > What would the advantage be of using Scala vs just normal Java?
> > Mostly from a curiosity standpoint; I've never done Scala so I don't
> > know it works.
> >
>
> The main advantage I can see is that most of the developers interested in
> working on v3 all prefer to work in Scala. I could go on and on about Scala
> over Java, but really, my comparison would all come down to functional
> programming over object oriented programming. When it comes to shared
> libraries like Log4j, I find Java far more appropriate and work in that
> space. In a GUI application where there is no real public API? I'd rather
> work in Scala. Kotlin was another option, but it seems like none of us
> really have experience there.
>
>
> > Did you actually have trouble building?  I'm pretty sure that when I
> > built it a few months ago I simply opened up the project in Netbeans
> > and it built immediately as a maven project(although looking at the
> > POM it does look like it uses ant on the backend for some reason).
> >
>
> Building the project is simple enough. I had issues with:
>
> 1. Running mvn clean install does not work by default unless you run "mvn
> site:site" before running "mvn install".
> 2. Doesn't build in Java 9.
> 3. The maven-release-plugin is not configured at all, so I had to do all
> release steps by hand instead.
>
> --
> Matt Sicker 
>

Re: Planning out what we can do to get Chainsaw back in the game

[Matt Sicker]

On 10 November 2017 at 16:17, Robert Middleton  wrote:

> What would the advantage be of using Scala vs just normal Java?
> Mostly from a curiosity standpoint; I've never done Scala so I don't
> know it works.
>

The main advantage I can see is that most of the developers interested in
working on v3 all prefer to work in Scala. I could go on and on about Scala
over Java, but really, my comparison would all come down to functional
programming over object oriented programming. When it comes to shared
libraries like Log4j, I find Java far more appropriate and work in that
space. In a GUI application where there is no real public API? I'd rather
work in Scala. Kotlin was another option, but it seems like none of us
really have experience there.


> Did you actually have trouble building?  I'm pretty sure that when I
> built it a few months ago I simply opened up the project in Netbeans
> and it built immediately as a maven project(although looking at the
> POM it does look like it uses ant on the backend for some reason).
>

Building the project is simple enough. I had issues with:

1. Running mvn clean install does not work by default unless you run "mvn
site:site" before running "mvn install".
2. Doesn't build in Java 9.
3. The maven-release-plugin is not configured at all, so I had to do all
release steps by hand instead.

-- 
Matt Sicker 

Re: Planning out what we can do to get Chainsaw back in the game

[Robert Middleton]

What would the advantage be of using Scala vs just normal Java?
Mostly from a curiosity standpoint; I've never done Scala so I don't
know it works.

Did you actually have trouble building?  I'm pretty sure that when I
built it a few months ago I simply opened up the project in Netbeans
and it built immediately as a maven project(although looking at the
POM it does look like it uses ant on the backend for some reason).

-Robert Middleton

On Fri, Nov 10, 2017 at 2:07 PM, Matt Sicker  wrote:
> Release candidate available. Based on my experiences here, I think one of
> the first useful things to do for 3.x would be to overhaul the build
> system. Since it seems like Scala may be the desired language to write this
> in, I may experiment with using SBT for the build instead of Maven+Ant.
>
> On 16 October 2017 at 18:47, Matt Sicker  wrote:
>
>> On 16 October 2017 at 16:11, Scott Deboy  wrote:
>>
>>> FYI, I think most folks just use pattern layout, which probably makes
>>> VFSLogFilePatternReceiver the most commonly used receiver.  Since it's
>>> VFS, anything accessible over SSH is retrievable and can be
>>> live-tailed.
>>>
>>
>> That would make sense since it doesn't have any dependencies and is the
>> typical way people configure logging. It's how I usually do it, too,
>> whether it's to the console or to a file.
>>
>>
>>> I use VFSLogFilePatternReceiver in my cloud configs to remotely tail
>>> logs from multiple hosts and combine those logs into a single view in
>>> Chainsaw.
>>>
>>
>> That's a pretty cool use case!
>>
>> --
>> Matt Sicker 
>>
>
>
>
> --
> Matt Sicker 

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Matt Sicker]

I can certainly update the screenshot for the site, though if it's embedded
in the bin archive, then that won't get updated. Thanks for verifying!

On 10 November 2017 at 14:43, Scott Deboy  wrote:

> Here's my +1.
>
> Site looks good, and it builds and runs.
>
> Thanks Matt
>
> On 11/10/17, Scott Deboy  wrote:
> > Updated screenshot.
> >
> > On 11/10/17, Scott Deboy  wrote:
> >> Awesome..I'll commit a new screenshot then.
> >>
> >> On 11/10/17, Ralph Goers  wrote:
> >>> The web site doesn’t have to be locked into the release.  An image can
> >>> be
> >>> updated after the release pretty easily.
> >>>
> >>> Ralph
> >>>
> >>>
>  On Nov 10, 2017, at 1:03 PM, Scott Deboy 
> wrote:
> 
>  Would it be possible for me to push an updated screenshot and re-spin?
> 
>  On 11/10/17, Scott Deboy  wrote:
> > Wow that screen shot looks ancient and ugly.  I should pull up
> > something on the Mac with updated default colors - it looks much
> > better.
> >
> > Scott
> >
> > On 11/10/17, Matt Sicker  wrote:
> >> Oh, and in case it isn't obvious how to test this, you can extract
> >> from
> >> either the zip or tar.gz files and run the chainsaw script in bin/
> >> corresponding to your operating system. Note that this crashes when
> >> using
> >> Java 9 for some reason, so make sure to use Java 6, 7, or 8.
> >>
> >> I built this using Java 1.8.0_111 on macOS 10.12.6.
> >>
> >> On 10 November 2017 at 13:04, Matt Sicker  wrote:
> >>
> >>> Quick note: using the maven-release-plugin doesn't seem to work in
> >>> this
> >>> project. Also, sources and documentation are included in the bin.*
> >>> files
> >>> while the standalone.* files are just the jars and startup scripts.
> >>>
> >>> On 10 November 2017 at 13:00, Matt Sicker 
> wrote:
> >>>
>  This is a vote to release Apache Chainsaw 2.0.0-rc1.
> 
>  (Note: I've created release instructions on the new wiki: <
>  https://cwiki.apache.org/confluence/display/LOGGING/Chainsa
>  w+Release+Guide>)
> 
>  Artifacts:
>  https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>  svn revision 23048
> 
>  Site:
>  http://musigma.org/chainsaw-site/
> 
>  Git:
>  https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
>  tag: chainsaw-2.0.0-rc1
> 
>  All artifacts have been signed by my PGP key
>  id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the
>  Logging
>  KEYS file.
> 
>  This vote will be open for at least 72 hours and requires at least
>  3
>  +1
>  votes and more +1 votes than -1 votes.
> 
>  --
>  Matt Sicker 
> 
> >>>
> >>>
> >>>
> >>> --
> >>> Matt Sicker 
> >>>
> >>
> >>
> >>
> >> --
> >> Matt Sicker 
> >>
> >
> 
> >>>
> >>>
> >>>
> >>
> >
>



-- 
Matt Sicker 

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

Here's my +1.

Site looks good, and it builds and runs.

Thanks Matt

On 11/10/17, Scott Deboy  wrote:
> Updated screenshot.
>
> On 11/10/17, Scott Deboy  wrote:
>> Awesome..I'll commit a new screenshot then.
>>
>> On 11/10/17, Ralph Goers  wrote:
>>> The web site doesn’t have to be locked into the release.  An image can
>>> be
>>> updated after the release pretty easily.
>>>
>>> Ralph
>>>
>>>
 On Nov 10, 2017, at 1:03 PM, Scott Deboy  wrote:

 Would it be possible for me to push an updated screenshot and re-spin?

 On 11/10/17, Scott Deboy  wrote:
> Wow that screen shot looks ancient and ugly.  I should pull up
> something on the Mac with updated default colors - it looks much
> better.
>
> Scott
>
> On 11/10/17, Matt Sicker  wrote:
>> Oh, and in case it isn't obvious how to test this, you can extract
>> from
>> either the zip or tar.gz files and run the chainsaw script in bin/
>> corresponding to your operating system. Note that this crashes when
>> using
>> Java 9 for some reason, so make sure to use Java 6, 7, or 8.
>>
>> I built this using Java 1.8.0_111 on macOS 10.12.6.
>>
>> On 10 November 2017 at 13:04, Matt Sicker  wrote:
>>
>>> Quick note: using the maven-release-plugin doesn't seem to work in
>>> this
>>> project. Also, sources and documentation are included in the bin.*
>>> files
>>> while the standalone.* files are just the jars and startup scripts.
>>>
>>> On 10 November 2017 at 13:00, Matt Sicker  wrote:
>>>
 This is a vote to release Apache Chainsaw 2.0.0-rc1.

 (Note: I've created release instructions on the new wiki: <
 https://cwiki.apache.org/confluence/display/LOGGING/Chainsa
 w+Release+Guide>)

 Artifacts:
 https://dist.apache.org/repos/dist/dev/logging/chainsaw/
 svn revision 23048

 Site:
 http://musigma.org/chainsaw-site/

 Git:
 https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
 tag: chainsaw-2.0.0-rc1

 All artifacts have been signed by my PGP key
 id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the
 Logging
 KEYS file.

 This vote will be open for at least 72 hours and requires at least
 3
 +1
 votes and more +1 votes than -1 votes.

 --
 Matt Sicker 

>>>
>>>
>>>
>>> --
>>> Matt Sicker 
>>>
>>
>>
>>
>> --
>> Matt Sicker 
>>
>

>>>
>>>
>>>
>>
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

Updated screenshot.

On 11/10/17, Scott Deboy  wrote:
> Awesome..I'll commit a new screenshot then.
>
> On 11/10/17, Ralph Goers  wrote:
>> The web site doesn’t have to be locked into the release.  An image can be
>> updated after the release pretty easily.
>>
>> Ralph
>>
>>
>>> On Nov 10, 2017, at 1:03 PM, Scott Deboy  wrote:
>>>
>>> Would it be possible for me to push an updated screenshot and re-spin?
>>>
>>> On 11/10/17, Scott Deboy  wrote:
 Wow that screen shot looks ancient and ugly.  I should pull up
 something on the Mac with updated default colors - it looks much
 better.

 Scott

 On 11/10/17, Matt Sicker  wrote:
> Oh, and in case it isn't obvious how to test this, you can extract
> from
> either the zip or tar.gz files and run the chainsaw script in bin/
> corresponding to your operating system. Note that this crashes when
> using
> Java 9 for some reason, so make sure to use Java 6, 7, or 8.
>
> I built this using Java 1.8.0_111 on macOS 10.12.6.
>
> On 10 November 2017 at 13:04, Matt Sicker  wrote:
>
>> Quick note: using the maven-release-plugin doesn't seem to work in
>> this
>> project. Also, sources and documentation are included in the bin.*
>> files
>> while the standalone.* files are just the jars and startup scripts.
>>
>> On 10 November 2017 at 13:00, Matt Sicker  wrote:
>>
>>> This is a vote to release Apache Chainsaw 2.0.0-rc1.
>>>
>>> (Note: I've created release instructions on the new wiki: <
>>> https://cwiki.apache.org/confluence/display/LOGGING/Chainsa
>>> w+Release+Guide>)
>>>
>>> Artifacts:
>>> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>>> svn revision 23048
>>>
>>> Site:
>>> http://musigma.org/chainsaw-site/
>>>
>>> Git:
>>> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
>>> tag: chainsaw-2.0.0-rc1
>>>
>>> All artifacts have been signed by my PGP key
>>> id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the
>>> Logging
>>> KEYS file.
>>>
>>> This vote will be open for at least 72 hours and requires at least 3
>>> +1
>>> votes and more +1 votes than -1 votes.
>>>
>>> --
>>> Matt Sicker 
>>>
>>
>>
>>
>> --
>> Matt Sicker 
>>
>
>
>
> --
> Matt Sicker 
>

>>>
>>
>>
>>
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

Would it be possible for me to push an updated screenshot and re-spin?

On 11/10/17, Scott Deboy  wrote:
> Wow that screen shot looks ancient and ugly.  I should pull up
> something on the Mac with updated default colors - it looks much
> better.
>
> Scott
>
> On 11/10/17, Matt Sicker  wrote:
>> Oh, and in case it isn't obvious how to test this, you can extract from
>> either the zip or tar.gz files and run the chainsaw script in bin/
>> corresponding to your operating system. Note that this crashes when using
>> Java 9 for some reason, so make sure to use Java 6, 7, or 8.
>>
>> I built this using Java 1.8.0_111 on macOS 10.12.6.
>>
>> On 10 November 2017 at 13:04, Matt Sicker  wrote:
>>
>>> Quick note: using the maven-release-plugin doesn't seem to work in this
>>> project. Also, sources and documentation are included in the bin.* files
>>> while the standalone.* files are just the jars and startup scripts.
>>>
>>> On 10 November 2017 at 13:00, Matt Sicker  wrote:
>>>
 This is a vote to release Apache Chainsaw 2.0.0-rc1.

 (Note: I've created release instructions on the new wiki: <
 https://cwiki.apache.org/confluence/display/LOGGING/Chainsa
 w+Release+Guide>)

 Artifacts:
 https://dist.apache.org/repos/dist/dev/logging/chainsaw/
 svn revision 23048

 Site:
 http://musigma.org/chainsaw-site/

 Git:
 https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
 tag: chainsaw-2.0.0-rc1

 All artifacts have been signed by my PGP key
 id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging
 KEYS file.

 This vote will be open for at least 72 hours and requires at least 3 +1
 votes and more +1 votes than -1 votes.

 --
 Matt Sicker 

>>>
>>>
>>>
>>> --
>>> Matt Sicker 
>>>
>>
>>
>>
>> --
>> Matt Sicker 
>>
>

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Scott Deboy]

Wow that screen shot looks ancient and ugly.  I should pull up
something on the Mac with updated default colors - it looks much
better.

Scott

On 11/10/17, Matt Sicker  wrote:
> Oh, and in case it isn't obvious how to test this, you can extract from
> either the zip or tar.gz files and run the chainsaw script in bin/
> corresponding to your operating system. Note that this crashes when using
> Java 9 for some reason, so make sure to use Java 6, 7, or 8.
>
> I built this using Java 1.8.0_111 on macOS 10.12.6.
>
> On 10 November 2017 at 13:04, Matt Sicker  wrote:
>
>> Quick note: using the maven-release-plugin doesn't seem to work in this
>> project. Also, sources and documentation are included in the bin.* files
>> while the standalone.* files are just the jars and startup scripts.
>>
>> On 10 November 2017 at 13:00, Matt Sicker  wrote:
>>
>>> This is a vote to release Apache Chainsaw 2.0.0-rc1.
>>>
>>> (Note: I've created release instructions on the new wiki: <
>>> https://cwiki.apache.org/confluence/display/LOGGING/Chainsa
>>> w+Release+Guide>)
>>>
>>> Artifacts:
>>> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>>> svn revision 23048
>>>
>>> Site:
>>> http://musigma.org/chainsaw-site/
>>>
>>> Git:
>>> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
>>> tag: chainsaw-2.0.0-rc1
>>>
>>> All artifacts have been signed by my PGP key
>>> id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging
>>> KEYS file.
>>>
>>> This vote will be open for at least 72 hours and requires at least 3 +1
>>> votes and more +1 votes than -1 votes.
>>>
>>> --
>>> Matt Sicker 
>>>
>>
>>
>>
>> --
>> Matt Sicker 
>>
>
>
>
> --
> Matt Sicker 
>

Re: Planning out what we can do to get Chainsaw back in the game

[Matt Sicker]

Release candidate available. Based on my experiences here, I think one of
the first useful things to do for 3.x would be to overhaul the build
system. Since it seems like Scala may be the desired language to write this
in, I may experiment with using SBT for the build instead of Maven+Ant.

On 16 October 2017 at 18:47, Matt Sicker  wrote:

> On 16 October 2017 at 16:11, Scott Deboy  wrote:
>
>> FYI, I think most folks just use pattern layout, which probably makes
>> VFSLogFilePatternReceiver the most commonly used receiver.  Since it's
>> VFS, anything accessible over SSH is retrievable and can be
>> live-tailed.
>>
>
> That would make sense since it doesn't have any dependencies and is the
> typical way people configure logging. It's how I usually do it, too,
> whether it's to the console or to a file.
>
>
>> I use VFSLogFilePatternReceiver in my cloud configs to remotely tail
>> logs from multiple hosts and combine those logs into a single view in
>> Chainsaw.
>>
>
> That's a pretty cool use case!
>
> --
> Matt Sicker 
>



-- 
Matt Sicker 

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Matt Sicker]

Quick note: using the maven-release-plugin doesn't seem to work in this
project. Also, sources and documentation are included in the bin.* files
while the standalone.* files are just the jars and startup scripts.

On 10 November 2017 at 13:00, Matt Sicker  wrote:

> This is a vote to release Apache Chainsaw 2.0.0-rc1.
>
> (Note: I've created release instructions on the new wiki: <
> https://cwiki.apache.org/confluence/display/LOGGING/Chainsaw+Release+Guide
> >)
>
> Artifacts:
> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
> svn revision 23048
>
> Site:
> http://musigma.org/chainsaw-site/
>
> Git:
> https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
> tag: chainsaw-2.0.0-rc1
>
> All artifacts have been signed by my PGP key id
> 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging KEYS
> file.
>
> This vote will be open for at least 72 hours and requires at least 3 +1
> votes and more +1 votes than -1 votes.
>
> --
> Matt Sicker 
>



-- 
Matt Sicker 

[VOTE] Release Apache Chainsaw 2.0.0-rc1

[Matt Sicker]

This is a vote to release Apache Chainsaw 2.0.0-rc1.

(Note: I've created release instructions on the new wiki: <
https://cwiki.apache.org/confluence/display/LOGGING/Chainsaw+Release+Guide>)

Artifacts:
https://dist.apache.org/repos/dist/dev/logging/chainsaw/
svn revision 23048

Site:
http://musigma.org/chainsaw-site/

Git:
https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
tag: chainsaw-2.0.0-rc1

All artifacts have been signed by my PGP key
id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging KEYS
file.

This vote will be open for at least 72 hours and requires at least 3 +1
votes and more +1 votes than -1 votes.

-- 
Matt Sicker 

Re: logging-log4j2 git commit: LOG4J2-2106 Reduce locking when checking for rollover

[Ralph Goers]

Please review this commit as I want to make sure I didn’t make any mistakes.

Ralph


> On Nov 10, 2017, at 6:46 AM, rgo...@apache.org wrote:
> 
> Repository: logging-log4j2
> Updated Branches:
>  refs/heads/master 0dca987fc -> aad2f132b
> 
> 
> LOG4J2-2106 Reduce locking when checking for rollover
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/aad2f132
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/aad2f132
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/aad2f132
> 
> Branch: refs/heads/master
> Commit: aad2f132b27f9e2667c2b43fb58ce59e3914edb3
> Parents: 0dca987
> Author: Ralph Goers 
> Authored: Fri Nov 10 06:46:11 2017 -0700
> Committer: Ralph Goers 
> Committed: Fri Nov 10 06:46:11 2017 -0700
> 
> --
> .../appender/rolling/RollingFileManager.java| 57 +---
> .../rolling/SizeBasedTriggeringPolicy.java  |  2 +-
> .../rolling/TimeBasedTriggeringPolicy.java  |  2 +-
> src/changes/changes.xml |  3 ++
> 4 files changed, 42 insertions(+), 22 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/aad2f132/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/RollingFileManager.java
> --
> diff --git 
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/RollingFileManager.java
>  
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/RollingFileManager.java
> index 6ccfe7b..ff7bf6d 100644
> --- 
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/RollingFileManager.java
> +++ 
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/RollingFileManager.java
> @@ -29,6 +29,9 @@ import java.util.concurrent.Semaphore;
> import java.util.concurrent.ThreadPoolExecutor;
> import java.util.concurrent.TimeUnit;
> import java.util.concurrent.atomic.AtomicReferenceFieldUpdater;
> +import java.util.concurrent.locks.Lock;
> +import java.util.concurrent.locks.ReadWriteLock;
> +import java.util.concurrent.locks.ReentrantReadWriteLock;
> 
> import org.apache.logging.log4j.core.Layout;
> import org.apache.logging.log4j.core.LifeCycle;
> @@ -65,6 +68,9 @@ public class RollingFileManager extends FileManager {
> private volatile boolean initialized = false;
> private volatile String fileName;
> private final FileExtension fileExtension;
> +private final ReadWriteLock updateLock = new ReentrantReadWriteLock();
> +private final Lock readLock = updateLock.readLock();
> +private final Lock writeLock = updateLock.writeLock();
> 
> /* This executor pool will create a new Thread for every work async 
> action to be performed. Using it allows
>us to make sure all the Threads are completed when the Manager is 
> stopped. */
> @@ -247,9 +253,14 @@ public class RollingFileManager extends FileManager {
>  * Determines if a rollover should occur.
>  * @param event The LogEvent.
>  */
> -public synchronized void checkRollover(final LogEvent event) {
> -if (triggeringPolicy.isTriggeringEvent(event)) {
> -rollover();
> +public void checkRollover(final LogEvent event) {
> +readLock.lock();
> +try {
> +if (triggeringPolicy.isTriggeringEvent(event)) {
> +rollover();
> +}
> +} finally {
> +readLock.unlock();
> }
> }
> 
> @@ -333,25 +344,31 @@ public class RollingFileManager extends FileManager {
> }
> 
> public void setTriggeringPolicy(final TriggeringPolicy triggeringPolicy) {
> -triggeringPolicy.initialize(this);
> -final TriggeringPolicy policy = this.triggeringPolicy;
> -int count = 0;
> -boolean policyUpdated = false;
> -do {
> -++count;
> -} while (!(policyUpdated = 
> triggeringPolicyUpdater.compareAndSet(this, this.triggeringPolicy, 
> triggeringPolicy))
> -&& count < MAX_TRIES);
> -if (policyUpdated) {
> -if (triggeringPolicy instanceof LifeCycle) {
> -((LifeCycle) triggeringPolicy).start();
> -}
> -if (policy instanceof LifeCycle) {
> -((LifeCycle) policy).stop();
> +writeLock.lock();
> +try {
> +triggeringPolicy.initialize(this);
> +final TriggeringPolicy policy = this.triggeringPolicy;
> +int count = 0;
> +boolean policyUpdated = false;
> +do {
> +++count;
> }
> -} else {
> -if (triggeringPolicy instanceof LifeCycle) {
> -