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

2017-11-11 Thread Scott Deboy
It's definitely always been a relatively simple 'log event-focused'/tabular
data tool. Basically:

- Pull in data from sources (usually files-local or ssh-able)
- parse the data into fields
- route the data to one or more tabs
- render the events into a table
- support filter, search, colorize and sort-all using a common expression
syntax, sort of a simpler version of logstash's grok.

Dashboard/visualization support would be awesome, but this is both a real
time as well as offline analysis tool. Cursor-style previous/next page
event rendering would make it a terrible user experience IMO.

Scott



On Nov 11, 2017 8:22 PM, "Ole Ersoy"  wrote:

> I had a brief peek.  My first impression was that the whole thing needs a
> facelift.  I'm currently I'm reviewing the ELK stack with the Kibana user
> interface as well as fluentd and Zipkin. Something that unifies these
> things would be very attractive.  If the UI is modern then even more so.
> If we can deploy it as a progressive web app attachable to a GraphQL
> provider that gets feeds from Fluentd and the ELK stack that would
> definitely get Chainsaw back in the game.  I think you would have an easy
> time attracting a talent pool for something like that.  For example
> http://akveo.github.io/blur-admin/ is currently available on Github and
> has 8000 stars.  Could be the starting point for the next generation
> logging UI.
>
> Cheers,
>
> Ole
>
>
> On 11/11/2017 06:09 PM, Scott Deboy wrote:
>
>> I'd love to hear what folks think of the user experience with the
>> 'latest Chainsaw' and its feature set.
>>
>> There are a ton of features.  It will be interesting to get a sense of
>> how many of those features we get 'for free' in any of these other UI
>> toolkits.  It was a lot of heavy lifting to get Swing to do what we
>> wanted.
>>
>> Scott
>>
>>
>> On 11/11/17, Ole Ersoy  wrote:
>>
>>> Kotlin is almost a duplicate of Typescript, so Javascript devs should be
>>> able to pickup on it fast.  There's a Typescript to Kotlin converter
>>> here:
>>>
>>> https://github.com/Kotlin/ts2kt
>>>
>>> Typescript is also supported in Electron:
>>>
>>> https://electron.atom.io/blog/2017/06/01/typescript
>>>
>>> So Kotlin should be a pretty good bridge between these worlds and opens
>>> up a
>>> lot of possibilities ... Suggested Kotlin to the Hipparchus group as
>>> well:
>>>
>>> https://github.com/Hipparchus-Math/hipparchus/issues/26
>>>
>>> A chainsaw implementation in Electron would provide a better developer
>>> and
>>> user experience I would think though ... as you can now use the latest
>>> Javascript frameworks (Angular / React) and all the packages that come
>>> with
>>> that ecosystem (Graphing, Widgets, etc.)
>>>
>>> https://scotch.io/tutorials/creating-desktop-applications-wi
>>> th-angularjs-and-github-electron
>>>
>>>
>>> On 11/11/2017 04:42 PM, Matt Sicker wrote:
>>>
 I've been using Java for years, Scala for several months (all of OOP,
 hybrid, and pure FP styles in different projects), and other languages
 in
 the past. I've certainly found Scala to be useful in the Big Data space,
 especially when using Spark, though I've also found it useful in
 projects
 that consume Java APIs.

 As for Kotlin fitting well to a GUI app, based on its traction in the
 Android GUI space, I had the same thought. Plus, this may attract more
 contributors outside ASF who are interested in using Kotlin or working
 on
 a
 GUI app instead of low level Java bits.

 Also, I'd imagine Kotlin is easier for a C# or JavaScript developer to
 pick
 up on than Scala, so that also helps with adoption in theory.

 On 11 November 2017 at 10:23, Mikael Ståldal  wrote:

 I have used both Java and Scala for several years, and I have been
> trying
> out Kotlin the latest months (for Android only).
>
> I would say it is definitely easier for a developer with primarily Java
> experience to pick up Kotlin than Scala, especially if that Java
> experience
> is predominately pre-Java8. If your primary experience is functional
> programming like Haskell, O'Caml or F#; then Scala is probably easier
> to
> pick up.
>
> Kotlin is gaining traction in Android, since it works well there. Scala
> is
> big in Big Data (Apache Spark etc) and to some extent in
> server/backend.
>
> Kotlin might be a better fit for a desktop UI Java app like Chainsaw.
>
>
>
> On 2017-11-11 02: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?
>>>
 

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

2017-11-11 Thread Ole Ersoy

I had a brief peek.  My first impression was that the whole thing needs a 
facelift.  I'm currently I'm reviewing the ELK stack with the Kibana user 
interface as well as fluentd and Zipkin. Something that unifies these things 
would be very attractive.  If the UI is modern then even more so.  If we can 
deploy it as a progressive web app attachable to a GraphQL provider that gets 
feeds from Fluentd and the ELK stack that would definitely get Chainsaw back in 
the game.  I think you would have an easy time attracting a talent pool for 
something like that.  For example http://akveo.github.io/blur-admin/ is 
currently available on Github and has 8000 stars.  Could be the starting point 
for the next generation logging UI.

Cheers,

Ole


On 11/11/2017 06:09 PM, Scott Deboy wrote:

I'd love to hear what folks think of the user experience with the
'latest Chainsaw' and its feature set.

There are a ton of features.  It will be interesting to get a sense of
how many of those features we get 'for free' in any of these other UI
toolkits.  It was a lot of heavy lifting to get Swing to do what we
wanted.

Scott


On 11/11/17, Ole Ersoy  wrote:

Kotlin is almost a duplicate of Typescript, so Javascript devs should be
able to pickup on it fast.  There's a Typescript to Kotlin converter here:

https://github.com/Kotlin/ts2kt

Typescript is also supported in Electron:

https://electron.atom.io/blog/2017/06/01/typescript

So Kotlin should be a pretty good bridge between these worlds and opens up a
lot of possibilities ... Suggested Kotlin to the Hipparchus group as well:

https://github.com/Hipparchus-Math/hipparchus/issues/26

A chainsaw implementation in Electron would provide a better developer and
user experience I would think though ... as you can now use the latest
Javascript frameworks (Angular / React) and all the packages that come with
that ecosystem (Graphing, Widgets, etc.)

https://scotch.io/tutorials/creating-desktop-applications-with-angularjs-and-github-electron


On 11/11/2017 04:42 PM, Matt Sicker wrote:

I've been using Java for years, Scala for several months (all of OOP,
hybrid, and pure FP styles in different projects), and other languages in
the past. I've certainly found Scala to be useful in the Big Data space,
especially when using Spark, though I've also found it useful in projects
that consume Java APIs.

As for Kotlin fitting well to a GUI app, based on its traction in the
Android GUI space, I had the same thought. Plus, this may attract more
contributors outside ASF who are interested in using Kotlin or working on
a
GUI app instead of low level Java bits.

Also, I'd imagine Kotlin is easier for a C# or JavaScript developer to
pick
up on than Scala, so that also helps with adoption in theory.

On 11 November 2017 at 10:23, Mikael Ståldal  wrote:


I have used both Java and Scala for several years, and I have been
trying
out Kotlin the latest months (for Android only).

I would say it is definitely easier for a developer with primarily Java
experience to pick up Kotlin than Scala, especially if that Java
experience
is predominately pre-Java8. If your primary experience is functional
programming like Haskell, O'Caml or F#; then Scala is probably easier to
pick up.

Kotlin is gaining traction in Android, since it works well there. Scala
is
big in Big Data (Apache Spark etc) and to some extent in server/backend.

Kotlin might be a better fit for a desktop UI Java app like Chainsaw.



On 2017-11-11 02: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 

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

2017-11-11 Thread Remko Popma
I’ve built several Swing-based apps and know Swing fairly well. I’ve only got 
my feet wet with JavaFX. 

Both are big frameworks with a significant learning curve. 

Personally I’d use JavaFX, if only to make working on the project an 
interesting learning experience. 

> On Nov 12, 2017, at 9:13, Matt Sicker  wrote:
> 
> I'll certainly be playing around with 2.0 for a bit before I can even
> determine what needs attention first anyways. I'm not super experienced
> with either Swing or JavaFX, so if it turns out that Swing is the more
> natural API to use based on your experiences, then it'd make sense to stick
> with that.
> 
>> On 11 November 2017 at 18:09, Scott Deboy  wrote:
>> 
>> I'd love to hear what folks think of the user experience with the
>> 'latest Chainsaw' and its feature set.
>> 
>> There are a ton of features.  It will be interesting to get a sense of
>> how many of those features we get 'for free' in any of these other UI
>> toolkits.  It was a lot of heavy lifting to get Swing to do what we
>> wanted.
>> 
>> Scott
>> 
>> 
>>> On 11/11/17, Ole Ersoy  wrote:
>>> Kotlin is almost a duplicate of Typescript, so Javascript devs should be
>>> able to pickup on it fast.  There's a Typescript to Kotlin converter
>> here:
>>> 
>>> https://github.com/Kotlin/ts2kt
>>> 
>>> Typescript is also supported in Electron:
>>> 
>>> https://electron.atom.io/blog/2017/06/01/typescript
>>> 
>>> So Kotlin should be a pretty good bridge between these worlds and opens
>> up a
>>> lot of possibilities ... Suggested Kotlin to the Hipparchus group as
>> well:
>>> 
>>> https://github.com/Hipparchus-Math/hipparchus/issues/26
>>> 
>>> A chainsaw implementation in Electron would provide a better developer
>> and
>>> user experience I would think though ... as you can now use the latest
>>> Javascript frameworks (Angular / React) and all the packages that come
>> with
>>> that ecosystem (Graphing, Widgets, etc.)
>>> 
>>> https://scotch.io/tutorials/creating-desktop-applications-
>> with-angularjs-and-github-electron
>>> 
>>> 
 On 11/11/2017 04:42 PM, Matt Sicker wrote:
 I've been using Java for years, Scala for several months (all of OOP,
 hybrid, and pure FP styles in different projects), and other languages
>> in
 the past. I've certainly found Scala to be useful in the Big Data space,
 especially when using Spark, though I've also found it useful in
>> projects
 that consume Java APIs.
 
 As for Kotlin fitting well to a GUI app, based on its traction in the
 Android GUI space, I had the same thought. Plus, this may attract more
 contributors outside ASF who are interested in using Kotlin or working
>> on
 a
 GUI app instead of low level Java bits.
 
 Also, I'd imagine Kotlin is easier for a C# or JavaScript developer to
 pick
 up on than Scala, so that also helps with adoption in theory.
 
> On 11 November 2017 at 10:23, Mikael Ståldal  wrote:
> 
> I have used both Java and Scala for several years, and I have been
> trying
> out Kotlin the latest months (for Android only).
> 
> I would say it is definitely easier for a developer with primarily Java
> experience to pick up Kotlin than Scala, especially if that Java
> experience
> is predominately pre-Java8. If your primary experience is functional
> programming like Haskell, O'Caml or F#; then Scala is probably easier
>> to
> pick up.
> 
> Kotlin is gaining traction in Android, since it works well there. Scala
> is
> big in Big Data (Apache Spark etc) and to some extent in
>> server/backend.
> 
> Kotlin might be a better fit for a desktop UI Java app like Chainsaw.
> 
> 
> 
>> On 2017-11-11 02: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.

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

2017-11-11 Thread Ralph Goers
Because the caller of newLogger(name) is AbstractLogger its ClassLoader will 
always be used. You need the ClassLoader of the caller of getLogger().

Ralph

> On Nov 11, 2017, at 3:43 PM, Gary Gregory  wrote:
> 
> Please code review git master. I'm not sure I have the class loader right.
> 
> Gary
> 
> On Sat, Nov 11, 2017 at 2:54 PM, Ralph Goers 
> wrote:
> 
>> Oh, but you probably don’t want to extend AbstractLogger. You really want
>> the FQCN of the caller to be able to identify the ClassLoader and
>> LoggerContext to use and you won’t get that from AbstractLogger’s getLogger
>> method.
>> 
>> Ralph
>> 
>>> On Nov 11, 2017, at 2:45 PM, Ralph Goers 
>> wrote:
>>> 
>>> Sure. Look at TomcatLogger. It does exactly what you are trying to do.
>>> 
>>> Ralph
>>> 
 On Nov 11, 2017, at 2:02 PM, Gary Gregory 
>> wrote:
 
 The Javadoc for Log4j's LoggerAdapter says "This registry should not be
 used for Log4j Loggers; it is instead used for creating bridges to other
 external log systems.".
 
 In this case we are not bridging TO another log system. We are plugging
 INTO Jetty's log system and subclassing Jetty's own LoggerAdapter class
 (out convenience.)
 
 Further thoughts?
 
 Gary
 
 On Fri, Nov 10, 2017 at 9:25 PM, Matt Sicker  wrote:
 
> IIRC, the easiest way to support it might be to use
> https://logging.apache.org/log4j/2.x/log4j-api/apidocs/
> org/apache/logging/log4j/spi/AbstractLoggerAdapter.html
> 
> On 10 November 2017 at 22:16, Gary Gregory 
>> wrote:
> 
>> I think you are correct...
>> 
>> Gary
>> 
>> On Fri, Nov 10, 2017 at 6:59 PM, Matt Sicker 
>> wrote:
>> 
>>> 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/
 

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

2017-11-11 Thread Matt Sicker
Oh, and there appear to be some JavaFX libraries out there for adding more
complex components/widgets/whatever they're called. It'd be interested to
see if the GUI code can be simplified using JavaFX.

On 11 November 2017 at 18:13, Matt Sicker  wrote:

> I'll certainly be playing around with 2.0 for a bit before I can even
> determine what needs attention first anyways. I'm not super experienced
> with either Swing or JavaFX, so if it turns out that Swing is the more
> natural API to use based on your experiences, then it'd make sense to stick
> with that.
>
> On 11 November 2017 at 18:09, Scott Deboy  wrote:
>
>> I'd love to hear what folks think of the user experience with the
>> 'latest Chainsaw' and its feature set.
>>
>> There are a ton of features.  It will be interesting to get a sense of
>> how many of those features we get 'for free' in any of these other UI
>> toolkits.  It was a lot of heavy lifting to get Swing to do what we
>> wanted.
>>
>> Scott
>>
>>
>> On 11/11/17, Ole Ersoy  wrote:
>> > Kotlin is almost a duplicate of Typescript, so Javascript devs should be
>> > able to pickup on it fast.  There's a Typescript to Kotlin converter
>> here:
>> >
>> > https://github.com/Kotlin/ts2kt
>> >
>> > Typescript is also supported in Electron:
>> >
>> > https://electron.atom.io/blog/2017/06/01/typescript
>> >
>> > So Kotlin should be a pretty good bridge between these worlds and opens
>> up a
>> > lot of possibilities ... Suggested Kotlin to the Hipparchus group as
>> well:
>> >
>> > https://github.com/Hipparchus-Math/hipparchus/issues/26
>> >
>> > A chainsaw implementation in Electron would provide a better developer
>> and
>> > user experience I would think though ... as you can now use the latest
>> > Javascript frameworks (Angular / React) and all the packages that come
>> with
>> > that ecosystem (Graphing, Widgets, etc.)
>> >
>> > https://scotch.io/tutorials/creating-desktop-applications-wi
>> th-angularjs-and-github-electron
>> >
>> >
>> > On 11/11/2017 04:42 PM, Matt Sicker wrote:
>> >> I've been using Java for years, Scala for several months (all of OOP,
>> >> hybrid, and pure FP styles in different projects), and other languages
>> in
>> >> the past. I've certainly found Scala to be useful in the Big Data
>> space,
>> >> especially when using Spark, though I've also found it useful in
>> projects
>> >> that consume Java APIs.
>> >>
>> >> As for Kotlin fitting well to a GUI app, based on its traction in the
>> >> Android GUI space, I had the same thought. Plus, this may attract more
>> >> contributors outside ASF who are interested in using Kotlin or working
>> on
>> >> a
>> >> GUI app instead of low level Java bits.
>> >>
>> >> Also, I'd imagine Kotlin is easier for a C# or JavaScript developer to
>> >> pick
>> >> up on than Scala, so that also helps with adoption in theory.
>> >>
>> >> On 11 November 2017 at 10:23, Mikael Ståldal  wrote:
>> >>
>> >>> I have used both Java and Scala for several years, and I have been
>> >>> trying
>> >>> out Kotlin the latest months (for Android only).
>> >>>
>> >>> I would say it is definitely easier for a developer with primarily
>> Java
>> >>> experience to pick up Kotlin than Scala, especially if that Java
>> >>> experience
>> >>> is predominately pre-Java8. If your primary experience is functional
>> >>> programming like Haskell, O'Caml or F#; then Scala is probably easier
>> to
>> >>> pick up.
>> >>>
>> >>> Kotlin is gaining traction in Android, since it works well there.
>> Scala
>> >>> is
>> >>> big in Big Data (Apache Spark etc) and to some extent in
>> server/backend.
>> >>>
>> >>> Kotlin might be a better fit for a desktop UI Java app like Chainsaw.
>> >>>
>> >>>
>> >>>
>> >>> On 2017-11-11 02: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.
>> >

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

2017-11-11 Thread Matt Sicker
I'll certainly be playing around with 2.0 for a bit before I can even
determine what needs attention first anyways. I'm not super experienced
with either Swing or JavaFX, so if it turns out that Swing is the more
natural API to use based on your experiences, then it'd make sense to stick
with that.

On 11 November 2017 at 18:09, Scott Deboy  wrote:

> I'd love to hear what folks think of the user experience with the
> 'latest Chainsaw' and its feature set.
>
> There are a ton of features.  It will be interesting to get a sense of
> how many of those features we get 'for free' in any of these other UI
> toolkits.  It was a lot of heavy lifting to get Swing to do what we
> wanted.
>
> Scott
>
>
> On 11/11/17, Ole Ersoy  wrote:
> > Kotlin is almost a duplicate of Typescript, so Javascript devs should be
> > able to pickup on it fast.  There's a Typescript to Kotlin converter
> here:
> >
> > https://github.com/Kotlin/ts2kt
> >
> > Typescript is also supported in Electron:
> >
> > https://electron.atom.io/blog/2017/06/01/typescript
> >
> > So Kotlin should be a pretty good bridge between these worlds and opens
> up a
> > lot of possibilities ... Suggested Kotlin to the Hipparchus group as
> well:
> >
> > https://github.com/Hipparchus-Math/hipparchus/issues/26
> >
> > A chainsaw implementation in Electron would provide a better developer
> and
> > user experience I would think though ... as you can now use the latest
> > Javascript frameworks (Angular / React) and all the packages that come
> with
> > that ecosystem (Graphing, Widgets, etc.)
> >
> > https://scotch.io/tutorials/creating-desktop-applications-
> with-angularjs-and-github-electron
> >
> >
> > On 11/11/2017 04:42 PM, Matt Sicker wrote:
> >> I've been using Java for years, Scala for several months (all of OOP,
> >> hybrid, and pure FP styles in different projects), and other languages
> in
> >> the past. I've certainly found Scala to be useful in the Big Data space,
> >> especially when using Spark, though I've also found it useful in
> projects
> >> that consume Java APIs.
> >>
> >> As for Kotlin fitting well to a GUI app, based on its traction in the
> >> Android GUI space, I had the same thought. Plus, this may attract more
> >> contributors outside ASF who are interested in using Kotlin or working
> on
> >> a
> >> GUI app instead of low level Java bits.
> >>
> >> Also, I'd imagine Kotlin is easier for a C# or JavaScript developer to
> >> pick
> >> up on than Scala, so that also helps with adoption in theory.
> >>
> >> On 11 November 2017 at 10:23, Mikael Ståldal  wrote:
> >>
> >>> I have used both Java and Scala for several years, and I have been
> >>> trying
> >>> out Kotlin the latest months (for Android only).
> >>>
> >>> I would say it is definitely easier for a developer with primarily Java
> >>> experience to pick up Kotlin than Scala, especially if that Java
> >>> experience
> >>> is predominately pre-Java8. If your primary experience is functional
> >>> programming like Haskell, O'Caml or F#; then Scala is probably easier
> to
> >>> pick up.
> >>>
> >>> Kotlin is gaining traction in Android, since it works well there. Scala
> >>> is
> >>> big in Big Data (Apache Spark etc) and to some extent in
> server/backend.
> >>>
> >>> Kotlin might be a better fit for a desktop UI Java app like Chainsaw.
> >>>
> >>>
> >>>
> >>> On 2017-11-11 02: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. 

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

2017-11-11 Thread Scott Deboy
I'd love to hear what folks think of the user experience with the
'latest Chainsaw' and its feature set.

There are a ton of features.  It will be interesting to get a sense of
how many of those features we get 'for free' in any of these other UI
toolkits.  It was a lot of heavy lifting to get Swing to do what we
wanted.

Scott


On 11/11/17, Ole Ersoy  wrote:
> Kotlin is almost a duplicate of Typescript, so Javascript devs should be
> able to pickup on it fast.  There's a Typescript to Kotlin converter here:
>
> https://github.com/Kotlin/ts2kt
>
> Typescript is also supported in Electron:
>
> https://electron.atom.io/blog/2017/06/01/typescript
>
> So Kotlin should be a pretty good bridge between these worlds and opens up a
> lot of possibilities ... Suggested Kotlin to the Hipparchus group as well:
>
> https://github.com/Hipparchus-Math/hipparchus/issues/26
>
> A chainsaw implementation in Electron would provide a better developer and
> user experience I would think though ... as you can now use the latest
> Javascript frameworks (Angular / React) and all the packages that come with
> that ecosystem (Graphing, Widgets, etc.)
>
> https://scotch.io/tutorials/creating-desktop-applications-with-angularjs-and-github-electron
>
>
> On 11/11/2017 04:42 PM, Matt Sicker wrote:
>> I've been using Java for years, Scala for several months (all of OOP,
>> hybrid, and pure FP styles in different projects), and other languages in
>> the past. I've certainly found Scala to be useful in the Big Data space,
>> especially when using Spark, though I've also found it useful in projects
>> that consume Java APIs.
>>
>> As for Kotlin fitting well to a GUI app, based on its traction in the
>> Android GUI space, I had the same thought. Plus, this may attract more
>> contributors outside ASF who are interested in using Kotlin or working on
>> a
>> GUI app instead of low level Java bits.
>>
>> Also, I'd imagine Kotlin is easier for a C# or JavaScript developer to
>> pick
>> up on than Scala, so that also helps with adoption in theory.
>>
>> On 11 November 2017 at 10:23, Mikael Ståldal  wrote:
>>
>>> I have used both Java and Scala for several years, and I have been
>>> trying
>>> out Kotlin the latest months (for Android only).
>>>
>>> I would say it is definitely easier for a developer with primarily Java
>>> experience to pick up Kotlin than Scala, especially if that Java
>>> experience
>>> is predominately pre-Java8. If your primary experience is functional
>>> programming like Haskell, O'Caml or F#; then Scala is probably easier to
>>> pick up.
>>>
>>> Kotlin is gaining traction in Android, since it works well there. Scala
>>> is
>>> big in Big Data (Apache Spark etc) and to some extent in server/backend.
>>>
>>> Kotlin might be a better fit for a desktop UI Java app like Chainsaw.
>>>
>>>
>>>
>>> On 2017-11-11 02: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 
>
>
>>
>
>


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

2017-11-11 Thread Ole Ersoy

Kotlin is almost a duplicate of Typescript, so Javascript devs should be able 
to pickup on it fast.  There's a Typescript to Kotlin converter here:

https://github.com/Kotlin/ts2kt

Typescript is also supported in Electron:

https://electron.atom.io/blog/2017/06/01/typescript

So Kotlin should be a pretty good bridge between these worlds and opens up a 
lot of possibilities ... Suggested Kotlin to the Hipparchus group as well:

https://github.com/Hipparchus-Math/hipparchus/issues/26

A chainsaw implementation in Electron would provide a better developer and user 
experience I would think though ... as you can now use the latest Javascript 
frameworks (Angular / React) and all the packages that come with that ecosystem 
(Graphing, Widgets, etc.)

https://scotch.io/tutorials/creating-desktop-applications-with-angularjs-and-github-electron


On 11/11/2017 04:42 PM, Matt Sicker wrote:

I've been using Java for years, Scala for several months (all of OOP,
hybrid, and pure FP styles in different projects), and other languages in
the past. I've certainly found Scala to be useful in the Big Data space,
especially when using Spark, though I've also found it useful in projects
that consume Java APIs.

As for Kotlin fitting well to a GUI app, based on its traction in the
Android GUI space, I had the same thought. Plus, this may attract more
contributors outside ASF who are interested in using Kotlin or working on a
GUI app instead of low level Java bits.

Also, I'd imagine Kotlin is easier for a C# or JavaScript developer to pick
up on than Scala, so that also helps with adoption in theory.

On 11 November 2017 at 10:23, Mikael Ståldal  wrote:


I have used both Java and Scala for several years, and I have been trying
out Kotlin the latest months (for Android only).

I would say it is definitely easier for a developer with primarily Java
experience to pick up Kotlin than Scala, especially if that Java experience
is predominately pre-Java8. If your primary experience is functional
programming like Haskell, O'Caml or F#; then Scala is probably easier to
pick up.

Kotlin is gaining traction in Android, since it works well there. Scala is
big in Big Data (Apache Spark etc) and to some extent in server/backend.

Kotlin might be a better fit for a desktop UI Java app like Chainsaw.



On 2017-11-11 02: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 








Re: logging-log4j-scala git commit: Add placeholder for Scala 2.13 but do not enable the module.

2017-11-11 Thread Gary Gregory
On Sat, Nov 11, 2017 at 3:51 PM, Matt Sicker  wrote:

> I've seen on Maven Central before that a few Scala libraries have published
> artifacts for 2.13.0 milestones. See for example: <
> https://search.maven.org/#artifactdetails%7Corg.
> scalatest%7Cscalatest_2.13.0-M2%7C3.0.4%7Cbundle>.
> It seems like if we published the module by naming it
> "log4j-api-scala_2.13.0-M2", we could have a version specific to that
> milestone at least.
>

Hi Matt,

The scalatest module has the milestone number in the name but not
scala-library for example.

Why bother with changing the module name. If it came out today, our version
12.0 of log4j-api-scala_2.13 would be at the 2.13.0-M2 level. Then our 13.0
can be at the next M level and so on.

What am I missing?

Gary


> On 11 November 2017 at 16:26,  wrote:
>
> > Repository: logging-log4j-scala
> > Updated Branches:
> >   refs/heads/master 5a71e5caa -> 184045cbc
> >
> >
> > Add placeholder for Scala 2.13 but do not enable the module.
> >
> > Project: http://git-wip-us.apache.org/repos/asf/logging-log4j-scala/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j-scala/
> > commit/184045cb
> > Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j-scala/
> > tree/184045cb
> > Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j-scala/
> > diff/184045cb
> >
> > Branch: refs/heads/master
> > Commit: 184045cbc7a517faef2a709aa68e83d7a0053599
> > Parents: 5a71e5c
> > Author: Gary Gregory 
> > Authored: Sat Nov 11 15:26:01 2017 -0700
> > Committer: Gary Gregory 
> > Committed: Sat Nov 11 15:26:01 2017 -0700
> >
> > --
> >  log4j-api-scala_2.13/pom.xml| 145 +
> >  .../org/apache/logging/log4j/scala/Logger.scala | 592
> +++
> >  .../logging/log4j/scala/LoggerMacro.scala   | 425 +
> >  .../apache/logging/log4j/scala/Logging.scala|  30 +
> >  .../logging/log4j/scala/LoggingContext.scala|  84 +++
> >  log4j-api-scala_2.13/src/site/markdown/index.md |  74 +++
> >  log4j-api-scala_2.13/src/site/site.xml  |  30 +
> >  .../apache/logging/log4j/scala/LoggerTest.scala | 552 +
> >  .../log4j/scala/LoggingContextTest.scala| 115 
> >  pom.xml |   1 +
> >  10 files changed, 2048 insertions(+)
> > --
> >
> >
> > http://git-wip-us.apache.org/repos/asf/logging-log4j-scala/
> > blob/184045cb/log4j-api-scala_2.13/pom.xml
> > --
> > diff --git a/log4j-api-scala_2.13/pom.xml b/log4j-api-scala_2.13/pom.xml
> > new file mode 100644
> > index 000..ea0f19c
> > --- /dev/null
> > +++ b/log4j-api-scala_2.13/pom.xml
> > @@ -0,0 +1,145 @@
> > +
> > +
> > +http://maven.apache.org/POM/4.0.0; xmlns:xsi="
> > http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://
> > maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> > +  4.0.0
> > +  
> > +org.apache.logging.log4j
> > +log4j-scala
> > +12.0-SNAPSHOT
> > +../
> > +  
> > +  log4j-api-scala_2.13
> > +  jar
> > +  Scala 2.13 wrapper for Log4j API
> > +  Scala wrapper for Log4j API
> > +  
> > +${basedir}/..
> > +/scala_2.13
> > +2.13.0-M2
> > +3.3.1
> > +1.8
> > +1.8
> > +  
> > +  
> > +
> > +  org.apache.logging.log4j
> > +  log4j-api
> > +
> > +
> > +  org.scala-lang
> > +  scala-library
> > +  ${scala.version}
> > +
> > +
> > +  org.scala-lang
> > +  scala-reflect
> > +  ${scala.version}
> > +
> > +
> > +  org.apache.logging.log4j
> > +  log4j-api
> > +  test-jar
> > +  test
> > +
> > +
> > +  junit
> > +  junit
> > +  test
> > +
> > +
> > +  org.scalatest
> > +  scalatest_2.13.0-M2
> > +  3.0.4
> > +  test
> > +
> > +
> > +  org.mockito
> > +  mockito-core
> > +  1.10.19
> > +  test
> > +
> > +  
> > +  
> > +src/main/scala
> > +src/test/scala
> > +
> > +  
> > +net.alchim31.maven
> > +scala-maven-plugin
> > +${scala.maven.plugin.version}
> > +
> > +  
> > +
> > +  compile
> > +  testCompile
> > +  doc-jar
> > +
> > +  
> > +
> > +
> > +  
> > +-feature
> > +-unchecked
> > +-deprecation
> > +  
> > +
> > +  
> > +  
> > +org.apache.maven.plugins
> > +maven-surefire-plugin
> > +  
> > +  
> > +org.apache.felix
> > +maven-bundle-plugin
> > +  
> > +
> > +  
> > +  
> > +
> > +  
> > +org.apache.maven.plugins
> > +

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

2017-11-11 Thread Matt Sicker
On 11 November 2017 at 14:44, Mikael Ståldal  wrote:

> On 2017-11-10 20:00, Matt Sicker wrote:
>
>> Artifacts:
>> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>> svn revision 23048
>>
>
> When I look at that URL, it says: Revision 23059
>

I gave a specific revision so that, if necessary, you can check out that
exact revision, though there are no updates in the linked directory since
r23048. The revision number shown on that page is global to the whole dist
repo.

-- 
Matt Sicker 


Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

2017-11-11 Thread Matt Sicker
Ah yes, I didn't note that correctly in the release wiki page. I've updated
the wiki.

On 11 November 2017 at 15:38, Mikael Ståldal  wrote:

> Yes, that worked.
>
>
>
> On 2017-11-11 22:22, Scott Deboy wrote:
>
>> I had ran mvn clean site:site install and it worked.
>>
>>
>> On 11/11/17, Mikael Ståldal  wrote:
>>
>>> On 2017-11-10 20:00, Matt Sicker wrote:
>>>
 Artifacts:
 https://dist.apache.org/repos/dist/dev/logging/chainsaw/
 svn revision 23048

>>>
>>> When I look at that URL, it says: Revision 23059
>>>
>>>
>>
>


-- 
Matt Sicker 


Re: logging-log4j-scala git commit: Add placeholder for Scala 2.13 but do not enable the module.

2017-11-11 Thread Matt Sicker
I've seen on Maven Central before that a few Scala libraries have published
artifacts for 2.13.0 milestones. See for example: <
https://search.maven.org/#artifactdetails%7Corg.scalatest%7Cscalatest_2.13.0-M2%7C3.0.4%7Cbundle>.
It seems like if we published the module by naming it
"log4j-api-scala_2.13.0-M2", we could have a version specific to that
milestone at least.

On 11 November 2017 at 16:26,  wrote:

> Repository: logging-log4j-scala
> Updated Branches:
>   refs/heads/master 5a71e5caa -> 184045cbc
>
>
> Add placeholder for Scala 2.13 but do not enable the module.
>
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j-scala/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j-scala/
> commit/184045cb
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j-scala/
> tree/184045cb
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j-scala/
> diff/184045cb
>
> Branch: refs/heads/master
> Commit: 184045cbc7a517faef2a709aa68e83d7a0053599
> Parents: 5a71e5c
> Author: Gary Gregory 
> Authored: Sat Nov 11 15:26:01 2017 -0700
> Committer: Gary Gregory 
> Committed: Sat Nov 11 15:26:01 2017 -0700
>
> --
>  log4j-api-scala_2.13/pom.xml| 145 +
>  .../org/apache/logging/log4j/scala/Logger.scala | 592 +++
>  .../logging/log4j/scala/LoggerMacro.scala   | 425 +
>  .../apache/logging/log4j/scala/Logging.scala|  30 +
>  .../logging/log4j/scala/LoggingContext.scala|  84 +++
>  log4j-api-scala_2.13/src/site/markdown/index.md |  74 +++
>  log4j-api-scala_2.13/src/site/site.xml  |  30 +
>  .../apache/logging/log4j/scala/LoggerTest.scala | 552 +
>  .../log4j/scala/LoggingContextTest.scala| 115 
>  pom.xml |   1 +
>  10 files changed, 2048 insertions(+)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j-scala/
> blob/184045cb/log4j-api-scala_2.13/pom.xml
> --
> diff --git a/log4j-api-scala_2.13/pom.xml b/log4j-api-scala_2.13/pom.xml
> new file mode 100644
> index 000..ea0f19c
> --- /dev/null
> +++ b/log4j-api-scala_2.13/pom.xml
> @@ -0,0 +1,145 @@
> +
> +
> +http://maven.apache.org/POM/4.0.0; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://
> maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> +  4.0.0
> +  
> +org.apache.logging.log4j
> +log4j-scala
> +12.0-SNAPSHOT
> +../
> +  
> +  log4j-api-scala_2.13
> +  jar
> +  Scala 2.13 wrapper for Log4j API
> +  Scala wrapper for Log4j API
> +  
> +${basedir}/..
> +/scala_2.13
> +2.13.0-M2
> +3.3.1
> +1.8
> +1.8
> +  
> +  
> +
> +  org.apache.logging.log4j
> +  log4j-api
> +
> +
> +  org.scala-lang
> +  scala-library
> +  ${scala.version}
> +
> +
> +  org.scala-lang
> +  scala-reflect
> +  ${scala.version}
> +
> +
> +  org.apache.logging.log4j
> +  log4j-api
> +  test-jar
> +  test
> +
> +
> +  junit
> +  junit
> +  test
> +
> +
> +  org.scalatest
> +  scalatest_2.13.0-M2
> +  3.0.4
> +  test
> +
> +
> +  org.mockito
> +  mockito-core
> +  1.10.19
> +  test
> +
> +  
> +  
> +src/main/scala
> +src/test/scala
> +
> +  
> +net.alchim31.maven
> +scala-maven-plugin
> +${scala.maven.plugin.version}
> +
> +  
> +
> +  compile
> +  testCompile
> +  doc-jar
> +
> +  
> +
> +
> +  
> +-feature
> +-unchecked
> +-deprecation
> +  
> +
> +  
> +  
> +org.apache.maven.plugins
> +maven-surefire-plugin
> +  
> +  
> +org.apache.felix
> +maven-bundle-plugin
> +  
> +
> +  
> +  
> +
> +  
> +org.apache.maven.plugins
> +maven-changes-plugin
> +${changes.plugin.version}
> +
> +  
> +
> +  changes-report
> +
> +  
> +
> +
> +  %URL%/show_bug.cgi?id=%ISSUE% issueLinkTemplate>
> +  true
> +
> +  
> +  
> +org.apache.maven.plugins
> +maven-pmd-plugin
> +${pmd.plugin.version}
> +
> +  ${maven.compiler.target}
> +
> +  
> +  
> +net.alchim31.maven
> +scala-maven-plugin
> +${scala.maven.plugin.version}
> +  
> +
> +  
> +
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j-scala/
> 

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

2017-11-11 Thread Gary Gregory
Please code review git master. I'm not sure I have the class loader right.

Gary

On Sat, Nov 11, 2017 at 2:54 PM, Ralph Goers 
wrote:

> Oh, but you probably don’t want to extend AbstractLogger. You really want
> the FQCN of the caller to be able to identify the ClassLoader and
> LoggerContext to use and you won’t get that from AbstractLogger’s getLogger
> method.
>
> Ralph
>
> > On Nov 11, 2017, at 2:45 PM, Ralph Goers 
> wrote:
> >
> > Sure. Look at TomcatLogger. It does exactly what you are trying to do.
> >
> > Ralph
> >
> >> On Nov 11, 2017, at 2:02 PM, Gary Gregory 
> wrote:
> >>
> >> The Javadoc for Log4j's LoggerAdapter says "This registry should not be
> >> used for Log4j Loggers; it is instead used for creating bridges to other
> >> external log systems.".
> >>
> >> In this case we are not bridging TO another log system. We are plugging
> >> INTO Jetty's log system and subclassing Jetty's own LoggerAdapter class
> >> (out convenience.)
> >>
> >> Further thoughts?
> >>
> >> Gary
> >>
> >> On Fri, Nov 10, 2017 at 9:25 PM, Matt Sicker  wrote:
> >>
> >>> IIRC, the easiest way to support it might be to use
> >>> https://logging.apache.org/log4j/2.x/log4j-api/apidocs/
> >>> org/apache/logging/log4j/spi/AbstractLoggerAdapter.html
> >>>
> >>> On 10 November 2017 at 22:16, Gary Gregory 
> wrote:
> >>>
>  I think you are correct...
> 
>  Gary
> 
>  On Fri, Nov 10, 2017 at 6:59 PM, Matt Sicker 
> wrote:
> 
> > 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 @@
> 

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

2017-11-11 Thread Matt Sicker
I've been using Java for years, Scala for several months (all of OOP,
hybrid, and pure FP styles in different projects), and other languages in
the past. I've certainly found Scala to be useful in the Big Data space,
especially when using Spark, though I've also found it useful in projects
that consume Java APIs.

As for Kotlin fitting well to a GUI app, based on its traction in the
Android GUI space, I had the same thought. Plus, this may attract more
contributors outside ASF who are interested in using Kotlin or working on a
GUI app instead of low level Java bits.

Also, I'd imagine Kotlin is easier for a C# or JavaScript developer to pick
up on than Scala, so that also helps with adoption in theory.

On 11 November 2017 at 10:23, Mikael Ståldal  wrote:

> I have used both Java and Scala for several years, and I have been trying
> out Kotlin the latest months (for Android only).
>
> I would say it is definitely easier for a developer with primarily Java
> experience to pick up Kotlin than Scala, especially if that Java experience
> is predominately pre-Java8. If your primary experience is functional
> programming like Haskell, O'Caml or F#; then Scala is probably easier to
> pick up.
>
> Kotlin is gaining traction in Android, since it works well there. Scala is
> big in Big Data (Apache Spark etc) and to some extent in server/backend.
>
> Kotlin might be a better fit for a desktop UI Java app like Chainsaw.
>
>
>
> On 2017-11-11 02: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 


Build failed in Jenkins: Log4jScala #71

2017-11-11 Thread Apache Jenkins Server
See 

Changes:

[ggregory] Add placeholder for Scala 2.13 but do not enable the module.

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on beam8 (beam) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/logging-log4j-scala.git # timeout=10
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/logging-log4j-scala.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/logging-log4j-scala.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 184045cbc7a517faef2a709aa68e83d7a0053599 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 184045cbc7a517faef2a709aa68e83d7a0053599
Commit message: "Add placeholder for Scala 2.13 but do not enable the module."
 > git rev-list 5a71e5caabdeb83a865971722836aecd131a25b2 # timeout=10
Parsing POMs
Established TCP socket on 42906
maven33-agent.jar already up to date
maven33-interceptor.jar already up to date
maven3-interceptor-commons.jar already up to date
[Log4jScala] $ /home/jenkins/tools/java/latest1.8/bin/java -Xmx2g -Xms256m -cp 
/home/jenkins/jenkins-slave/maven33-agent.jar:/home/jenkins/tools/maven/apache-maven-3.3.9/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.3.9/conf/logging
 jenkins.maven3.agent.Maven33Main /home/jenkins/tools/maven/apache-maven-3.3.9 
/home/jenkins/jenkins-slave/slave.jar 
/home/jenkins/jenkins-slave/maven33-interceptor.jar 
/home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 42906
<===[JENKINS REMOTING CAPACITY]===>   channel started
Executing Maven:  -B -f  
-Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/1 clean 
install site
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] Unresolveable build extension: Plugin 
org.apache.felix:maven-bundle-plugin:3.3.0 or one of its dependencies could not 
be resolved: Failure to find org.apache.felix:maven-bundle-plugin:jar:3.3.0 in 
https://repo.maven.apache.org/maven2 was cached in the local repository, 
resolution will not be reattempted until the update interval of central has 
elapsed or updates are forced @ 
[ERROR] Unresolveable build extension: Plugin 
org.apache.felix:maven-bundle-plugin:3.3.0 or one of its dependencies could not 
be resolved: Failure to find org.apache.felix:maven-bundle-plugin:jar:3.3.0 in 
https://repo.maven.apache.org/maven2 was cached in the local repository, 
resolution will not be reattempted until the update interval of central has 
elapsed or updates are forced @ 
[ERROR] Unresolveable build extension: Plugin 
org.apache.felix:maven-bundle-plugin:3.3.0 or one of its dependencies could not 
be resolved: Failure to find org.apache.felix:maven-bundle-plugin:jar:3.3.0 in 
https://repo.maven.apache.org/maven2 was cached in the local repository, 
resolution will not be reattempted until the update interval of central has 
elapsed or updates are forced @ 
[ERROR] Unresolveable build extension: Plugin 
org.apache.felix:maven-bundle-plugin:3.3.0 or one of its dependencies could not 
be resolved: Failure to find org.apache.felix:maven-bundle-plugin:jar:3.3.0 in 
https://repo.maven.apache.org/maven2 was cached in the local repository, 
resolution will not be reattempted until the update interval of central has 
elapsed or updates are forced @ 
 @ 
[ERROR] The build could not read 4 projects -> [Help 1]
[ERROR]   
[ERROR]   The project 
org.apache.logging.log4j:log4j-api-scala_2.10:12.0-SNAPSHOT 
( 
has 1 error
[ERROR] Unresolveable build extension: Plugin 
org.apache.felix:maven-bundle-plugin:3.3.0 or one of its dependencies could not 
be resolved: Failure to find org.apache.felix:maven-bundle-plugin:jar:3.3.0 in 
https://repo.maven.apache.org/maven2 was cached in the local repository, 
resolution will not be reattempted until the update interval of central has 
elapsed or updates are forced -> [Help 2]
[ERROR]   
[ERROR]   The project 
org.apache.logging.log4j:log4j-api-scala_2.11:12.0-SNAPSHOT 
( 
has 1 error
[ERROR] Unresolveable build extension: Plugin 
org.apache.felix:maven-bundle-plugin:3.3.0 or one of its dependencies could not 
be resolved: Failure to find org.apache.felix:maven-bundle-plugin:jar:3.3.0 in 
https://repo.maven.apache.org/maven2 

Build failed in Jenkins: Log4jScala #70

2017-11-11 Thread Apache Jenkins Server
See 

Changes:

[ggregory] scala.maven.plugin.version 3.2.2 -> 3.3.1.

[ggregory] scala.maven.plugin.version 3.2.2 -> 3.3.1.

[ggregory] [LOG4J2-2116] Update Scala from 2.12.3 to 2.12.4.

[ggregory] [LOG4J2-2116] Update Scala from 2.12.3 to 2.12.4.

[ggregory] [LOG4J2-2116] Update log4j-api-scala_2.12 from Scala 2.12.3 to 
2.12.4.

--
Started by an SCM change
Started by an SCM change
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on beam8 (beam) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/logging-log4j-scala.git # timeout=10
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/logging-log4j-scala.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/logging-log4j-scala.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 5a71e5caabdeb83a865971722836aecd131a25b2 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 5a71e5caabdeb83a865971722836aecd131a25b2
Commit message: "[LOG4J2-2116] Update log4j-api-scala_2.12 from Scala 2.12.3 to 
2.12.4."
 > git rev-list 50132758f666bde3be440bd258389c5bb91dada9 # timeout=10
Parsing POMs
Modules changed, recalculating dependency graph
Established TCP socket on 41235
maven33-agent.jar already up to date
maven33-interceptor.jar already up to date
maven3-interceptor-commons.jar already up to date
[Log4jScala] $ /home/jenkins/tools/java/latest1.8/bin/java -Xmx2g -Xms256m -cp 
/home/jenkins/jenkins-slave/maven33-agent.jar:/home/jenkins/tools/maven/apache-maven-3.3.9/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.3.9/conf/logging
 jenkins.maven3.agent.Maven33Main /home/jenkins/tools/maven/apache-maven-3.3.9 
/home/jenkins/jenkins-slave/slave.jar 
/home/jenkins/jenkins-slave/maven33-interceptor.jar 
/home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 41235
<===[JENKINS REMOTING CAPACITY]===>   channel started
Executing Maven:  -B -f  
-Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/1 clean 
install site
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] Unresolveable build extension: Plugin 
org.apache.felix:maven-bundle-plugin:3.3.0 or one of its dependencies could not 
be resolved: Failure to find org.apache.felix:maven-bundle-plugin:jar:3.3.0 in 
https://repo.maven.apache.org/maven2 was cached in the local repository, 
resolution will not be reattempted until the update interval of central has 
elapsed or updates are forced @ 
[ERROR] Unresolveable build extension: Plugin 
org.apache.felix:maven-bundle-plugin:3.3.0 or one of its dependencies could not 
be resolved: Failure to find org.apache.felix:maven-bundle-plugin:jar:3.3.0 in 
https://repo.maven.apache.org/maven2 was cached in the local repository, 
resolution will not be reattempted until the update interval of central has 
elapsed or updates are forced @ 
[ERROR] Unresolveable build extension: Plugin 
org.apache.felix:maven-bundle-plugin:3.3.0 or one of its dependencies could not 
be resolved: Failure to find org.apache.felix:maven-bundle-plugin:jar:3.3.0 in 
https://repo.maven.apache.org/maven2 was cached in the local repository, 
resolution will not be reattempted until the update interval of central has 
elapsed or updates are forced @ 
[ERROR] Unresolveable build extension: Plugin 
org.apache.felix:maven-bundle-plugin:3.3.0 or one of its dependencies could not 
be resolved: Failure to find org.apache.felix:maven-bundle-plugin:jar:3.3.0 in 
https://repo.maven.apache.org/maven2 was cached in the local repository, 
resolution will not be reattempted until the update interval of central has 
elapsed or updates are forced @ 
 @ 
[ERROR] The build could not read 4 projects -> [Help 1]
[ERROR]   
[ERROR]   The project 
org.apache.logging.log4j:log4j-api-scala_2.10:12.0-SNAPSHOT 
( 
has 1 error
[ERROR] Unresolveable build extension: Plugin 
org.apache.felix:maven-bundle-plugin:3.3.0 or one of its dependencies could not 
be resolved: Failure to find org.apache.felix:maven-bundle-plugin:jar:3.3.0 in 
https://repo.maven.apache.org/maven2 was cached in the local repository, 
resolution will not be reattempted until the update interval of central has 
elapsed or updates are forced -> [Help 2]
[ERROR]   
[ERROR]   The project 

Build failed in Jenkins: Log4jScala #69

2017-11-11 Thread Apache Jenkins Server
See 

Changes:

[ggregory] Update scalatest_2.11 from 3.0.0 to 3.0.4.

[ggregory] Update scalatest_2.12 from 3.0.0 to 3.0.4.

[ggregory] maven-bundle-plugin 3.2.0 -> 3.3.0

[ggregory] maven-pmd-plugin 3.7 -> 3.8

[ggregory] Set Maven version prerequisite to 3.0.5.

[ggregory] RAT plug did not have its version set.

[ggregory] Assembly plugin did not have its version set.

[ggregory] scala.maven.plugin.version 3.2.2 -> 3.3.1.

[ggregory] Update Log4j2 from 2.8.2 to 2.9.1.

[ggregory] [LOG4J2-2115] Update Log4j dependency from 2.8.1 to 2.9.1.

--
[...truncated 68.03 KB...]
[WARNING]  org.apache.logging.log4j:log4j-api-scala_2.12:12.0-SNAPSHOT requires 
scala version: 2.12.3
[WARNING]  org.scala-lang:scala-reflect:2.12.3 requires scala version: 2.12.3
[WARNING]  org.scalatest:scalatest_2.12:3.0.4 requires scala version: 2.12.3
[WARNING]  org.scalactic:scalactic_2.12:3.0.4 requires scala version: 2.12.3
[WARNING]  org.scala-lang.modules:scala-xml_2.12:1.0.5 requires scala version: 
2.12.0
[WARNING] Multiple versions of scala libraries detected!
model contains 10 documentable templates
:59:
 warning: Variable user.getName undefined in comment for class Logger in class 
Logger
  * logger.debug(s"Logging in user ${user.getName} with birthday 
${user.calcBirthday}")
^
:59:
 warning: Variable user.calcBirthday undefined in comment for class Logger in 
class Logger
  * logger.debug(s"Logging in user ${user.getName} with birthday 
${user.calcBirthday}")
  ^
two warnings found
[INFO] Generating "Dependencies" report --- 
maven-project-info-reports-plugin:2.9:dependencies
[INFO] Generating "Dependency Information" report --- 
maven-project-info-reports-plugin:2.9:dependency-info
[INFO] Generating "Dependency Management" report --- 
maven-project-info-reports-plugin:2.9:dependency-management
[INFO] Generating "Distribution Management" report --- 
maven-project-info-reports-plugin:2.9:distribution-management
[INFO] Generating "Issue Management" report --- 
maven-project-info-reports-plugin:2.9:issue-tracking
[INFO] Generating "Licenses" report --- 
maven-project-info-reports-plugin:2.9:license
[INFO] Generating "Mailing Lists" report--- 
maven-project-info-reports-plugin:2.9:mailing-list
[INFO] Generating "Plugin Management" report--- 
maven-project-info-reports-plugin:2.9:plugin-management
[INFO] Generating "Plugins" report  --- 
maven-project-info-reports-plugin:2.9:plugins
[INFO] Generating "Source Code Management" report --- 
maven-project-info-reports-plugin:2.9:scm
[INFO] Generating "Summary" report  --- 
maven-project-info-reports-plugin:2.9:summary
[JENKINS] Archiving site from 
 
to /x1/jenkins/jenkins-home/jobs/Log4jScala/site/log4j-api-scala_2.12
[INFO] 
[INFO] 
[INFO] Building Scala API samples 12.0-SNAPSHOT
[INFO] 
[INFO] Downloading: 
https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-core/2.9.1/log4j-core-2.9.1.jar
[INFO] Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-core/2.9.1/log4j-core-2.9.1.jar
 (1514 KB at 17006.1 KB/sec)
[INFO] 
[INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @ 
log4j-api-scala-sample ---
[INFO] Deleting 

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (process-resource-bundles) 
@ log4j-api-scala-sample ---
[INFO] 
[INFO] --- maven-resources-plugin:2.7:resources (default-resources) @ 
log4j-api-scala-sample ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.5.1:compile (default-compile) @ 
log4j-api-scala-sample ---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] --- scala-maven-plugin:3.2.2:compile (default) @ log4j-api-scala-sample 
---
[WARNING]  Expected all dependencies to require Scala version: 2.12.1
[WARNING]  org.apache.logging.log4j:log4j-api-scala_2.12:12.0-SNAPSHOT requires 
scala version: 2.12.3
[WARNING] Multiple versions of scala libraries detected!
[INFO] 
:-1:
 info: compiling
[INFO] Compiling 1 source 

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

2017-11-11 Thread Ralph Goers
Oh, but you probably don’t want to extend AbstractLogger. You really want the 
FQCN of the caller to be able to identify the ClassLoader and LoggerContext to 
use and you won’t get that from AbstractLogger’s getLogger method.

Ralph

> On Nov 11, 2017, at 2:45 PM, Ralph Goers  wrote:
> 
> Sure. Look at TomcatLogger. It does exactly what you are trying to do.
> 
> Ralph
> 
>> On Nov 11, 2017, at 2:02 PM, Gary Gregory  wrote:
>> 
>> The Javadoc for Log4j's LoggerAdapter says "This registry should not be
>> used for Log4j Loggers; it is instead used for creating bridges to other
>> external log systems.".
>> 
>> In this case we are not bridging TO another log system. We are plugging
>> INTO Jetty's log system and subclassing Jetty's own LoggerAdapter class
>> (out convenience.)
>> 
>> Further thoughts?
>> 
>> Gary
>> 
>> On Fri, Nov 10, 2017 at 9:25 PM, Matt Sicker  wrote:
>> 
>>> IIRC, the easiest way to support it might be to use
>>> https://logging.apache.org/log4j/2.x/log4j-api/apidocs/
>>> org/apache/logging/log4j/spi/AbstractLoggerAdapter.html
>>> 
>>> On 10 November 2017 at 22:16, Gary Gregory  wrote:
>>> 
 I think you are correct...
 
 Gary
 
 On Fri, Nov 10, 2017 at 6:59 PM, Matt Sicker  wrote:
 
> 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 

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

2017-11-11 Thread Ralph Goers
Sure. Look at TomcatLogger. It does exactly what you are trying to do.

Ralph

> On Nov 11, 2017, at 2:02 PM, Gary Gregory  wrote:
> 
> The Javadoc for Log4j's LoggerAdapter says "This registry should not be
> used for Log4j Loggers; it is instead used for creating bridges to other
> external log systems.".
> 
> In this case we are not bridging TO another log system. We are plugging
> INTO Jetty's log system and subclassing Jetty's own LoggerAdapter class
> (out convenience.)
> 
> Further thoughts?
> 
> Gary
> 
> On Fri, Nov 10, 2017 at 9:25 PM, Matt Sicker  wrote:
> 
>> IIRC, the easiest way to support it might be to use
>> https://logging.apache.org/log4j/2.x/log4j-api/apidocs/
>> org/apache/logging/log4j/spi/AbstractLoggerAdapter.html
>> 
>> On 10 November 2017 at 22:16, Gary Gregory  wrote:
>> 
>>> I think you are correct...
>>> 
>>> Gary
>>> 
>>> On Fri, Nov 10, 2017 at 6:59 PM, Matt Sicker  wrote:
>>> 
 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 

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

2017-11-11 Thread Mikael Ståldal

Yes, that worked.


On 2017-11-11 22:22, Scott Deboy wrote:

I had ran mvn clean site:site install and it worked.


On 11/11/17, Mikael Ståldal  wrote:

On 2017-11-10 20:00, Matt Sicker wrote:

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


When I look at that URL, it says: Revision 23059







Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

2017-11-11 Thread Scott Deboy
I had ran mvn clean site:site install and it worked.


On 11/11/17, Mikael Ståldal  wrote:
> On 2017-11-10 20:00, Matt Sicker wrote:
>> Artifacts:
>> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>> svn revision 23048
>
> When I look at that URL, it says: Revision 23059
>


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

2017-11-11 Thread Daan Hoogland
Thanks, I'm trying the commitish build install use.

Sent from Nine

From: Ralph Goers 
Sent: 11 Nov 2017 8:45 pm
To: dev@logging.apache.org
Subject: Re: logging-log4j2 git commit: LOG4J2-2106 Reduce locking when 
checking for rollover

Release candidates are only available on the Apache staging repository. The 
download information will be in the email for the release candidate.

Ralph




Senior Software Developer
daan.hoogl...@shapeblue.com
www.shapeblue.com
 
 

> On Nov 11, 2017, at 10:59 AM, Daan Hoogland  
> wrote:
>
> As a matter of interest, can we test release candidates from maven central at 
> apache or do I need to build and install locally to test?
>
> thanks
>
> On 11/11/2017, 18:32, "Ralph Goers"  wrote:
>
>Ok. I’m waiting on feedback on this before I start a release.
>
>Ralph
>
>
>
> Senior Software Developer
> daan.hoogl...@shapeblue.com
> www.shapeblue.com
>
>
>
>> On Nov 11, 2017, at 7:14 AM, Remko Popma  wrote:
>>
>> I’ll take a look tomorrow.
>>
>>
>>
>>> On Nov 10, 2017, at 22:47, Ralph Goers  wrote:
>>>
>>> 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) {
 +   

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

2017-11-11 Thread Gary Gregory
The Javadoc for Log4j's LoggerAdapter says "This registry should not be
used for Log4j Loggers; it is instead used for creating bridges to other
external log systems.".

In this case we are not bridging TO another log system. We are plugging
INTO Jetty's log system and subclassing Jetty's own LoggerAdapter class
(out convenience.)

Further thoughts?

Gary

On Fri, Nov 10, 2017 at 9:25 PM, Matt Sicker  wrote:

> IIRC, the easiest way to support it might be to use
> https://logging.apache.org/log4j/2.x/log4j-api/apidocs/
> org/apache/logging/log4j/spi/AbstractLoggerAdapter.html
>
> On 10 November 2017 at 22:16, Gary Gregory  wrote:
>
> > I think you are correct...
> >
> > Gary
> >
> > On Fri, Nov 10, 2017 at 6:59 PM, Matt Sicker  wrote:
> >
> > > 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 

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

2017-11-11 Thread Mikael Ståldal

On 2017-11-10 20:00, Matt Sicker wrote:

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


When I look at that URL, it says: Revision 23059


Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

2017-11-11 Thread Mikael Ståldal

Same issue on master branch.

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-10T17:41:47+01:00)

Java version: 1.8.0_144, vendor: Oracle Corporation
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", arch: "amd64", family: "unix"


On 2017-11-11 21:40, Mikael Ståldal wrote:

$ git checkout chainsaw-2.0.0-rc1

$ mvn clean install

[...]

[INFO] --- maven-assembly-plugin:2.4:single (make-assembly) @ 
apache-chainsaw ---
Downloading: 
https://repo.maven.apache.org/maven2/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar 

Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar 
(0 B at 0.0 KB/sec)

[INFO] Reading assembly descriptor: src/assembly/bin.xml
[INFO] 


[INFO] BUILD FAILURE
[INFO] 


[INFO] Total time: 17.828 s
[INFO] Finished at: 2017-11-11T21:31:50+01:00
[INFO] Final Memory: 31M/382M
[INFO] 

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:2.4:single 
(make-assembly) on project apache-chainsaw: site did not exist in the 
target directory - please run site:site before creating the assembly: 
Mojo configuration is invalid: site did not exist in the target 
directory - please run site:site before creating the assembly -> [Help 1]

[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the 
-e switch.

[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, 
please read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException




On 2017-11-10 20: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.







Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

2017-11-11 Thread Mikael Ståldal

$ git checkout chainsaw-2.0.0-rc1

$ mvn clean install

[...]

[INFO] --- maven-assembly-plugin:2.4:single (make-assembly) @ 
apache-chainsaw ---
Downloading: 
https://repo.maven.apache.org/maven2/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar 
(0 B at 0.0 KB/sec)

[INFO] Reading assembly descriptor: src/assembly/bin.xml
[INFO] 


[INFO] BUILD FAILURE
[INFO] 


[INFO] Total time: 17.828 s
[INFO] Finished at: 2017-11-11T21:31:50+01:00
[INFO] Final Memory: 31M/382M
[INFO] 

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:2.4:single 
(make-assembly) on project apache-chainsaw: site did not exist in the 
target directory - please run site:site before creating the assembly: 
Mojo configuration is invalid: site did not exist in the target 
directory - please run site:site before creating the assembly -> [Help 1]

[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the 
-e switch.

[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, 
please read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException




On 2017-11-10 20: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.





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

2017-11-11 Thread Ralph Goers
Release candidates are only available on the Apache staging repository. The 
download information will be in the email for the release candidate.

Ralph


> On Nov 11, 2017, at 10:59 AM, Daan Hoogland  
> wrote:
> 
> As a matter of interest, can we test release candidates from maven central at 
> apache or do I need to build and install locally to test?
> 
> thanks
> 
> On 11/11/2017, 18:32, "Ralph Goers"  wrote:
> 
>Ok. I’m waiting on feedback on this before I start a release.
> 
>Ralph
> 
> 
> 
> Senior Software Developer
> daan.hoogl...@shapeblue.com
> www.shapeblue.com
> 
> 
> 
>> On Nov 11, 2017, at 7:14 AM, Remko Popma  wrote:
>> 
>> I’ll take a look tomorrow. 
>> 
>> 
>> 
>>> On Nov 10, 2017, at 22:47, Ralph Goers  wrote:
>>> 
>>> 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 

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

2017-11-11 Thread Ralph Goers
Ok. I’m waiting on feedback on this before I start a release.

Ralph

> On Nov 11, 2017, at 7:14 AM, Remko Popma  wrote:
> 
> I’ll take a look tomorrow. 
> 
> 
> 
>> On Nov 10, 2017, at 22:47, Ralph Goers  wrote:
>> 
>> 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) {

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

2017-11-11 Thread Mikael Ståldal
I have used both Java and Scala for several years, and I have been 
trying out Kotlin the latest months (for Android only).


I would say it is definitely easier for a developer with primarily Java 
experience to pick up Kotlin than Scala, especially if that Java 
experience is predominately pre-Java8. If your primary experience is 
functional programming like Haskell, O'Caml or F#; then Scala is 
probably easier to pick up.


Kotlin is gaining traction in Android, since it works well there. Scala 
is big in Big Data (Apache Spark etc) and to some extent in server/backend.


Kotlin might be a better fit for a desktop UI Java app like Chainsaw.


On 2017-11-11 02: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 







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

2017-11-11 Thread Remko Popma
I’ll take a look tomorrow. 



> On Nov 10, 2017, at 22:47, Ralph Goers  wrote:
> 
> 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;
>> +