Re: Container Log Collection for Microservices

[Ole Ersoy]

Just came across something related for amazon lambda:

https://medium.freecodecamp.org/how-to-implement-log-aggregation-for-aws-lambda-ca714bf02f48

Quote:

Dur­ing the exe­cu­tion of a Lamb­da func­tion, what­ev­er you write to std­out 
(for example, using|console.log|in Node.js) will be cap­tured by Lamb­da and 
sent to Cloud­Watch Logs asyn­chro­nous­ly in the back­ground.

Still does not answer the "Why" on the performance question, but I thought it 
was interesting ...

Cheers,

Ole



On 04/03/2018 04:25 PM, Ralph Goers wrote:

Thanks. That is helpful but it still doesn’t answer the question I was asking, 
although it does provide good documentation on what people are recommending for 
how to configure applications for the cloud.

Testing at Log4j has shown that writing to stdout is magnitudes slower than 
logging to a file, even when stdout is redirected to a file. What I am 
wondering, and still haven’t found an answer to, is whether this performance 
degradation is present when a Java app is running in a docker container and 
logs to stdout.

Ralph


On Apr 3, 2018, at 11:44 AM, Ole Ersoy <ole.er...@gmail.com> wrote:

I accidentally deleted the original thread, but saw that there were some 
questions surrounding logging to stdout (I assume while running in a 
microservice dockerized environment).

You might find these article helpful:
http://callistaenterprise.se/blogg/teknik/2017/07/29/building-microservices-part-7-distributed-tracing/
http://callistaenterprise.se/blogg/teknik/2017/09/13/building-microservices-part-8-logging-with-ELK/

These cover log event collection for both ELK and Zipkin.  Parts 1-6 in the 
series are really good as well if you want to know more about microservices and 
security in general with the Spring and Netflix OSS stack.  Originally came 
across it while looking for OAuth material.

Cheers,
Ole

Re: Container Log Collection for Microservices

[Ole Ersoy]

I plan on playing with the microservices from the tutorial more in the near 
future.  I could:

1) Load test one microservice without stdout logging

2) Load test with stdout logging

3) See if there is any response degradation recorded by zipkin

Would be nice to see if Prometheus records any additional overhead as well 
(Next tutorial).

Once I get the setup I'll ping back.

IIUC the reason we are logging to stdout in docker containers is just so we can 
see the logging output when running the container during development.  We fire 
up the container and do some sanity testing with cURL and look at the log 
output with docker logs or docker compose logs.

Once we are happy we can turn off the logging to standard out and do file based 
logging or something more advanced with ELK and Zipkin.

Perhaps the docker layer handling the stdout stream is slow or that managing 
the buffer it uses is a performance bottle neck.

Cheers,
Ole




On 04/03/2018 04:25 PM, Ralph Goers wrote:

Thanks. That is helpful but it still doesn’t answer the question I was asking, 
although it does provide good documentation on what people are recommending for 
how to configure applications for the cloud.

Testing at Log4j has shown that writing to stdout is magnitudes slower than 
logging to a file, even when stdout is redirected to a file. What I am 
wondering, and still haven’t found an answer to, is whether this performance 
degradation is present when a Java app is running in a docker container and 
logs to stdout.

Ralph


On Apr 3, 2018, at 11:44 AM, Ole Ersoy <ole.er...@gmail.com> wrote:

I accidentally deleted the original thread, but saw that there were some 
questions surrounding logging to stdout (I assume while running in a 
microservice dockerized environment).

You might find these article helpful:
http://callistaenterprise.se/blogg/teknik/2017/07/29/building-microservices-part-7-distributed-tracing/
http://callistaenterprise.se/blogg/teknik/2017/09/13/building-microservices-part-8-logging-with-ELK/

These cover log event collection for both ELK and Zipkin.  Parts 1-6 in the 
series are really good as well if you want to know more about microservices and 
security in general with the Spring and Netflix OSS stack.  Originally came 
across it while looking for OAuth material.

Cheers,
Ole

Container Log Collection for Microservices

[Ole Ersoy]

I accidentally deleted the original thread, but saw that there were some 
questions surrounding logging to stdout (I assume while running in a 
microservice dockerized environment).

You might find these article helpful:
http://callistaenterprise.se/blogg/teknik/2017/07/29/building-microservices-part-7-distributed-tracing/
http://callistaenterprise.se/blogg/teknik/2017/09/13/building-microservices-part-8-logging-with-ELK/

These cover log event collection for both ELK and Zipkin.  Parts 1-6 in the 
series are really good as well if you want to know more about microservices and 
security in general with the Spring and Netflix OSS stack.  Originally came 
across it while looking for OAuth material.

Cheers,
Ole

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

[Ole Ersoy]

On 01/21/2018 07:58 AM, Mikael Ståldal wrote:

Nothing stops you from starting your own log viewer project based on whatever 
technology you want. If it turns out useful, we might even consider adopting it 
as an Apache Logging subproject.

Indeed I'm right in the middle of starting a CSS project and I have 26 modules 
thus far:
https://www.npmjs.com/search?q=%40superflycss
https://github.com/superflycss/superflycss

I also suggested Kotlin to Hipparchus.  Right tool for the right job:
https://github.com/Hipparchus-Math/hipparchus/issues/26

If you are running a restaurant but the Chefs are limited to a bowl and spoon 
in what they create, I think you will find that the restaurant's market appeal 
will be fairly constrained, and the same goes for the chefs that want to work 
in / with the restaurant.

Cheers,
Ole


I think it's better if you and we try out what we believe in independently, and 
then we will see what works best.


On 2018-01-20 21:32, Ole Ersoy wrote:

Still pretty certain you would attract a lot more talent / downloads / interest 
in general with Visual Studio Code (Typescript) and Stackblitz:

https://stackblitz.com/

It's essentially Kotlin but a lot more feature rich.

Ole

On 01/20/2018 12:00 PM, Matt Sicker wrote:

I've put out rc2 now that we have some fixes in place there.

My professional situation has changed since I proposed this. Nowadays, I've
been using Kotlin for a project, and I'd have to say that it would be far
more appropriate than Scala here due to being easier to learn as a Java
developer (or just in general) along with better overlap with Java best
practices (Kotlin is essentially a language inspired by Effective Java).
Plus, now that Android developers are getting more familiar with Kotlin as
well which could potentially attract contributors (besides being a hip cool
language or whatever).

On 13 November 2017 at 17:35, Ole Ersoy <ole.er...@gmail.com> wrote:


Here's a 10 minute video where an Angular timer application is built and
packaged for all desktops (Apple, M$, Linux - And all browsers) ... in 10
minutes.

https://www.youtube.com/watch?v=u_vMChpZMCk

If you use the youtube speedup chrome extension you can probably set the
speedup factor to 2 or 3.  That cuts it down to 3 minutes.

https://chrome.google.com/webstore/detail/youtube-playback-
speed-co/hdannnflhlmdablckfkjpleikpphncik?hl=en-US

Love that thing!



On 11/12/2017 11:37 PM, Ralph Goers wrote:


It feels to me that this whole topic has gotten side-tracked.

I think you first need to decide what you want to build before you decide
on technologies.  Are you building a web application or a desktop? Of
course, there might be technology that lets you do both, to some degree. As
far as I know, the only viable language for web applications is Javascript,
unless you want to build browser plugins. While there might be more variety
in desktop applications, the usefulness might be more limited - but maybe
not. After all, there are still a whole lot of desktop based tools around.

But then you have apps like Microsoft Office where they have built a web
version and a Windows desktop version and a Mac OS desktop version. I have
no idea how much, if any, of that code is shared, but again, that is an
option that could be considered.

So again, before going down the rabbit hole of technology discussion,
what is the scope of what the next version of Chainsaw will be?  Will it be
an upgraded version of the existing code base that uses something besides
Swing, will it be something else, or do we want multiple spin-off projects?

Ralph

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

[Ole Ersoy]

Still pretty certain you would attract a lot more talent / downloads / interest 
in general with Visual Studio Code (Typescript) and Stackblitz:

https://stackblitz.com/

It's essentially Kotlin but a lot more feature rich.

Ole

On 01/20/2018 12:00 PM, Matt Sicker wrote:

I've put out rc2 now that we have some fixes in place there.

My professional situation has changed since I proposed this. Nowadays, I've
been using Kotlin for a project, and I'd have to say that it would be far
more appropriate than Scala here due to being easier to learn as a Java
developer (or just in general) along with better overlap with Java best
practices (Kotlin is essentially a language inspired by Effective Java).
Plus, now that Android developers are getting more familiar with Kotlin as
well which could potentially attract contributors (besides being a hip cool
language or whatever).

On 13 November 2017 at 17:35, Ole Ersoy <ole.er...@gmail.com> wrote:


Here's a 10 minute video where an Angular timer application is built and
packaged for all desktops (Apple, M$, Linux - And all browsers) ... in 10
minutes.

https://www.youtube.com/watch?v=u_vMChpZMCk

If you use the youtube speedup chrome extension you can probably set the
speedup factor to 2 or 3.  That cuts it down to 3 minutes.

https://chrome.google.com/webstore/detail/youtube-playback-
speed-co/hdannnflhlmdablckfkjpleikpphncik?hl=en-US

Love that thing!



On 11/12/2017 11:37 PM, Ralph Goers wrote:


It feels to me that this whole topic has gotten side-tracked.

I think you first need to decide what you want to build before you decide
on technologies.  Are you building a web application or a desktop? Of
course, there might be technology that lets you do both, to some degree. As
far as I know, the only viable language for web applications is Javascript,
unless you want to build browser plugins. While there might be more variety
in desktop applications, the usefulness might be more limited - but maybe
not. After all, there are still a whole lot of desktop based tools around.

But then you have apps like Microsoft Office where they have built a web
version and a Windows desktop version and a Mac OS desktop version. I have
no idea how much, if any, of that code is shared, but again, that is an
option that could be considered.

So again, before going down the rabbit hole of technology discussion,
what is the scope of what the next version of Chainsaw will be?  Will it be
an upgraded version of the existing code base that uses something besides
Swing, will it be something else, or do we want multiple spin-off projects?

Ralph

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

[Ole Ersoy]

Here's a 10 minute video where an Angular timer application is built and 
packaged for all desktops (Apple, M$, Linux - And all browsers) ... in 10 
minutes.

https://www.youtube.com/watch?v=u_vMChpZMCk

If you use the youtube speedup chrome extension you can probably set the 
speedup factor to 2 or 3.  That cuts it down to 3 minutes.

https://chrome.google.com/webstore/detail/youtube-playback-speed-co/hdannnflhlmdablckfkjpleikpphncik?hl=en-US

Love that thing!


On 11/12/2017 11:37 PM, Ralph Goers wrote:

It feels to me that this whole topic has gotten side-tracked.

I think you first need to decide what you want to build before you decide on 
technologies.  Are you building a web application or a desktop? Of course, 
there might be technology that lets you do both, to some degree. As far as I 
know, the only viable language for web applications is Javascript, unless you 
want to build browser plugins. While there might be more variety in desktop 
applications, the usefulness might be more limited - but maybe not. After all, 
there are still a whole lot of desktop based tools around.

But then you have apps like Microsoft Office where they have built a web 
version and a Windows desktop version and a Mac OS desktop version. I have no 
idea how much, if any, of that code is shared, but again, that is an option 
that could be considered.

So again, before going down the rabbit hole of technology discussion, what is 
the scope of what the next version of Chainsaw will be?  Will it be an upgraded 
version of the existing code base that uses something besides Swing, will it be 
something else, or do we want multiple spin-off projects?

Ralph

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

[Ole Ersoy]

So to summarize Qt would lead to shoe horning in all the things that are simple 
to do and constantly being improved and optimized with Angular or ReactJS and 
most of the use cases I mentioned are not supported.

Quality > quantity

True but you have a really good quality indicator in the number of downloads 
per module on the NPM page.  For example take the superagent REST client 
written by TJ Holowaychuck (Also authored the express framework).  So for a 
quality indicator just review the stats:
https://www.npmjs.com/package/superagent

 * *65,261*downloads in the last day
 * *1,421,783*downloads in the last week
 * *5,688,991*downloads in the last month


Worst of all he wrote it when he was 6 years old while taking a break from a 
Photography shoot.

  and need I bring up the left-pad fiasco? There's no
namespacing on npm

It's called an @organization.  For instance angular lives under @angular.

, and the artifacts aren't even immutable!

Most of the popular packages use semver guidelines.  You can also shrinkwrap 
the build.


  It took how
many build tools before reproducible builds were possible? (yarn)

Been using NPM for years now and reproducible builds have always just worked.  
They introduced a glitch while introducing package-lock.json, but it was fixed 
quickly (I hope) :).  Also with all the traffic around Angular, in addition to 
the weight that Google puts behind it, the builds will be reproducible.





It could also lead to more sharply focused feature development in Log4J.


Like what? Log4j has been rather healthy with feature development,
especially in comparison to literally every other JVM logging solution in
existence.

Absolutely - I love the new log4j features.  That's why I'm on this list.  However 
logging feels like it's a bit of an after thought when it comes to development.  I've 
seen very few articles detailing out "This is how you use logging to nail down 
issues with this type of scenario".  This is when you trigger a switch from the info 
log level to the warn log level realtime, etc.  In other words a type of methodology 
around logging that is integrated with how we think about developing the application / 
server in general and how we go about using logging results on a day to day basis.

So we have all these tool - Spring has the Actuator - we have ELK, Zipkin, 
fluentd, Elastic Search, Log4J + other things you mentioned in your last 
article - but what is the best way to put all this together and integrate it 
into the development design flow so that the logging solution is an integrated 
part of the final product that minimally invasive, easy to setup and monitor, 
and user / dev ops friendly.





In this case you could just flip to the app and see the logging alerts
real time via a socket connection.  The app could also vibrate your phone
if the S*** is going down.  You would just configure the app to talk to the
notification server.  It could give you rich and informative realtime
visualization of how an attack on your network and services is unfolding /
how nodes are performing overall and peaceful pictures of koala bears
eating leaves when everything is under control.  You know no one can resist
Koalas!


This could be a useful app, though it's rather orthogonal to Chainsaw IMO.

Well it's just food for thought ... I definitely think it would bring Chainsaw 
back into the game and pump up log4j in general  If there is a doable 
vision articulated around it then interested parties would know where and how 
to contribute ... I don't think this would hurt anyones resume ...

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

[Ole Ersoy]

If you'd like to contribute a proof of concept, that would be great! I'm
not a fan of frontend web development anymore

Given how much variation there has been in package formats etc. (UMD, AMD, 
CommonJS, God help us D, etc) I don't blame you.  Just AOT compile, Babelify 
it, then rollupJS it, then Webpack it, smack it and definitely track it.

  (see my comments earlier
about Elm being one of the sane places to work there), so I don't know how
much I could help with that.

Looking at implementing ELK and Zipkin ATM as well as implementing some sort of 
unified dashboard thing for all of it, so hope to have something in this space 
soon.  The whole thing is simmering down quite a bit with the Angular 5 release 
and the angular CLI, so I'm not going to be shocked if it changes your view on 
front end development.

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

[Ole Ersoy]

On 11/12/2017 07:23 PM, Matt Sicker wrote:


On 12 November 2017 at 13:52, Ole Ersoy <ole.er...@gmail.com> wrote:


With a progressive Angularjs Webapp it will be a realtime / offline /
cached and web deployable analysis tool.  You can deploy it to browsers,
your phone, the desktop.  The browser can cache assets such that the app is
always available.  Need to store a bunch of logs offline in the browser -
use PouchDB.  The whole thing can be wrapped in electron to make it a
desktop application.  Need observables to observe, throttle, debounce,
filter, map etc. log results as they are coming in?  Use RXJS.  Etc. etc.
etc.


You can do all this with Qt and some other GUI toolkits.

Dude  Seriously??? ... Even if you can the developer pool for that is a 
tiny fraction of what you get with a modern web application architecture.  
Which organizations are investing in Qt?
- Can you deploy a Qt app on github pages?
- Can you cache a Qt app as an application via a web url?
- Can you automatically convert the Qt webapp into a mobile app for any phone 
architecture?
- Can you run D3 visualizations in a Qt app?
- Can you run any web component in a Qt app?
- Can you reuse your Qt skills with other web application technologies to 
create mobile or in browser progressive web apps?
- Can you run Qt easily in a browser?
- Does Qt look like Java (As in Typescript?)
- What are the IDE options with Qt?
- Can you package the Qt app to be installable on any platform?
- How many GraphQL clients can we choose between for Qt?
- Can you reuse your qt web components inside a browser?  Any browser?
etc

Angular had over 1 million downloads last month:
https://www.npmjs.com/package/angular

How many did Qt have?

That's just angular core.  If you look at the stats for some of the supporting 
libraries you'll see they are quite similar.  When is the last time you read 
about how to deploy your Qt web app?


Have you seen Maven Central? It makes the NPM ecosystem look, well,
unprofessional.

Bro - you are kidding?  Been using Maven central for 15 years.  Just filled out 
a JIRA for an account so I can publish math artifacts a month ago and I'm still 
waiting to hear on whether it's going to be approved or not.  I'm starting to 
get the feeling I'm being ignored ...  On the flip side I registered the 
hipparchus-math organization myself a few days ago on NPM (Just in case 
hipparchus wants to use Kotlin and start publishing javascript artifacts to NPM 
in order to expand hipparchus reach) and I publish almost daily to NPM with 
zero friction.  You just type npm publish and your package is there available 
for everyone to use.  I suspect the NPM eco system is growing at a rate of 
1000X the maven ecosystem.  For anything you can find in Java you will find at 
least 30 of them on NPM.

NPM had 183,830,829
downloads today.  How many did Maven central have?  Honestly, not sure if you 
have used NPM much, but once you do you will very very  very very very ... 
very very delighted.  Want a simple rest server to play with to simulate log 
event publishing - here you go:
https://github.com/typicode/json-server

NPM is just stuffed with super useful everythings that are easy to use and 
experiment with ...




For colors I would mimic a Stock Exchange, Crypto Exchange (See the HODL
cryptocurrency phone app).  That way administrators have good realtime
metaphor for what's going on in their systems.


I haven't really looked much at what you're saying,

No one ever does :).

  but the design ideas
could be interesting.

This should reflect well on Log4J too.  Having it be part of something that's 
universally useful to both individual developers and large organizations / dev 
ops puts it in in a whole new light. Would not be shocked if ELK stack, 
FluentD, and Zipkin devs would take notice and jump onboard either.  It could 
also lead to more sharply focused feature development in Log4J.





Install the mobile version on a phone and set it to receive events that
have a hacking signature, etc


This could be useful, though I feel like it might be simpler to just set up
alerting via an app you actually use more often (e.g., getting an email or
chat notification).

In this case you could just flip to the app and see the logging alerts real 
time via a socket connection.  The app could also vibrate your phone if the 
S*** is going down.  You would just configure the app to talk to the 
notification server.  It could give you rich and informative realtime 
visualization of how an attack on your network and services is unfolding / how 
nodes are performing overall and peaceful pictures of koala bears eating leaves 
when everything is under control.  You know no one can resist Koalas!

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

[Ole Ersoy]

ES is pretty simple to use. It has a lot of neat features for text
searching as well. That doesn't stop people from pretending it's a NoSQL
database, however.

If you use it with PouchDB, localStorage, or session storage then it's a NoSQL 
database.  PouchDB also features sync replication with CouchDB.

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

[Ole Ersoy]

I haven't had a chance to dive into the code yet, but I'd imagine that
there may be some sort of boundary in place (or can be put in place)
between the UI and the logic such that multiple UIs can reuse the same
code. That sort of pattern is not specific to web development. :)

One of the reasons I decided on Angular rather than React for web development is that it's good 
at components.  We can now create custom components for the browser, like 
.  So for instance there could be a  
component, etc.  The testing framework that comes with it is also very good.  Most of the time 
there's no need for a web server.  Most services can be mocked on tested in the browser.

Typescript and Kotlin are near duplicates and Angular uses Typescript for 
component and UI development.  Obviously it's up to you, but I think you'll get 
a lot more mileage and reward out of your effort if you upgrade the platform.


On 12 November 2017 at 08:50, Mikael Ståldal <mi...@apache.org> wrote:


Having said that, I don't mean that Ole Ersoy's idea is inherently bad.
But it should be a new independent project (possibly in Apache Logging
Services).



On 2017-11-12 14:27, Mikael Ståldal wrote:


To me, that sound like transforming it into something completely
different, and a use case which there already exists quite some other tools
for already.

Shouldn't we keep Chainsaw as a stand-alone desktop UI app?


On 2017-11-12 05:22, 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 <ole.er...@gmail.com> 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 <mi...@apache.org>
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 wrot

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

[Ole Ersoy]

On 11/12/2017 07:24 AM, Mikael Ståldal wrote:

On 2017-11-12 00:57, Ole Ersoy wrote:
> A chainsaw implementation in Electron would provide a better developer
> and user experience I would think though

But that would require a complete rewrite of the app, with no opportunity to 
reuse any of the existing Java code.

I tend to look at code as just a blueprint proven blueprint / good set of 
guidelines for how to implement something.



Both Scala and Kotlin have good interoperability with Java, and you can mix 
them with Java in the same project. So we can to a gradual migration.

To me it looks like a migration to nowhere, but if you have users and clients that are in 
need of that then by all means.  Judging by the subject I thought this was "Lets 
turn this 1960 corvette into a Tesla" type discussion.



Or am I missing something?

You are missing something (Just me being smart - don't kill me).


I have also heard that Electron has been criticized for having a very heavy 
runtime (embedded Chrome browser). That is to some extent true with the JVM 
also, but I think that Electron is worse.

Have you used Atom?  All (Probably) UI developers have it at their disposal.  
It drives Elektron development.  It's constantly being worked on by Github and 
a gazillion open source developers.  No one has to use Elektron.  Just deploy 
the app to github pages and allow users to use it as a progressive webapp.  
Electron is just one more deployment option in addition to browser and mobile.

Here are some of the Apps built with Elektron:
https://electron.atom.io/apps/

Most (If not all) have a github repository.  This Angular 5 video is pretty 
good:

https://www.youtube.com/watch?v=oa9cnWTpqP8

I would think the whole thing could be turned into a decent Angular 5 app in a 
few days.  After that I'm sure it will do all sorts of things as it's now a 
much more attractive base to iterate on.

Cheers,
Ole

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

[Ole Ersoy]

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.

With a progressive Angularjs Webapp it will be a realtime / offline / cached 
and web deployable analysis tool.  You can deploy it to browsers, your phone, 
the desktop.  The browser can cache assets such that the app is always 
available.  Need to store a bunch of logs offline in the browser - use PouchDB. 
 The whole thing can be wrapped in electron to make it a desktop application.  
Need observables to observe, throttle, debounce, filter, map etc. log results 
as they are coming in?  Use RXJS.  Etc. etc. etc.

It should connect to RESTful or GraphQL endpoints (Elasticsearch, FluentD 
sources), or load files directly from the desktop.  The number of widgets and 
widget frameworks that are accessible with angular is crazy ... but with a 
Javascript client there's also D3.js etc:

https://d3js.org/
http://jtblin.github.io/angular-chart.js/
http://krispo.github.io/angular-nvd3/#/

Plus now you also have the entire NPM ecosystem:
https://www.npmjs.com/

It's like going from cabin to the Chocolate Factory!  Don't chew the gum.

For colors I would mimic a Stock Exchange, Crypto Exchange (See the HODL 
cryptocurrency phone app).  That way administrators have good realtime metaphor 
for what's going on in their systems.

Install the mobile version on a phone and set it to receive events that have a 
hacking signature, etc

Ole

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

[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 <ole.er...@gmail.com> 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 <mi...@apache.org> 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 <boa...@gmail.com> wrote:

On 10 November 2017 at 16:17, Robert Middleton <osfan6...@gmail.com>

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-r

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

[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: [meta] Draft blog post about logging in general

[Ole Ersoy]

Wow - That looks REALLY USEFUL.  BTW - Mangnus Larsson has this really great 
ELK stack tutorial.  Might be helpful in general ... 
http://callistaenterprise.se/blogg/teknik/2017/09/13/building-microservices-part-8-logging-with-ELK/


On 11/03/2017 01:50 PM, Matt Sicker wrote:

I also just found out about another similar log aggregation project which
could be useful to add in the examples: https://www.fluentd.org/

On 31 October 2017 at 16:26, Matt Sicker  wrote:


On 31 October 2017 at 16:06, Mikael Ståldal  wrote:

Maybe Logstash and Graylog should be refered to as "products" rather than
"projects".


Makes sense.



And since Logstash doesn't really provide the desired functionallity by
itself, maybe refer to the "ELK stack" instead.


Also makes sense. I'm so used to using Elasticsearch by itself, I tend to
forget it's also part of that stack.


--
Matt Sicker 

Re: [meta] Draft blog post about logging in general

[Ole Ersoy]

That's the key - Gotta make it more fun!  Keep it fresh - Ziplock fresh!  
Freshaliciouss!!


On 10/30/2017 04:14 PM, Matt Sicker wrote:

Zipkin is a fun topic I wrote a small internal blog post at my client
about. The general topic I'm doing a talk on is "The How and Why of
Logging" which is generally aimed at providing an overview of logging
concepts, common libraries, tools, patterns, etc. Distributed log tracing
is certainly a topic I was considering talking about in the talk provided
it doesn't go too long.

On 30 October 2017 at 15:52, Ole Ersoy <ole.er...@gmail.com> wrote:


Probably a series of blog posts :).  Another thing that would be great is
pumping up some of the new features that log4j2 has that developers will
love.  It reads a little bit like a theoretical intro to logging in general
(Although you did say clearly that that is what it is) and we have a lot of
material like that, so what is it about the presentation that should make
your peers want to pay attention?  I'm sure you'll find that even if the
audience have heard of some of the new log4j2 features, they'll appreciate
a recap.  For example here's a pretty good article on Kotlin that I
recently read:

http://petersommerhoff.com/dev/kotlin/kotlin-for-java-devs/

A specific example of how to log from both a project dependency, as well
as the core project code, would be great as well.  The FAQ is good, but it
feels a little bit like reading your Denon Receiver's manual ...

Could be that throwing in Zipkin (http://zipkin.io/) with the rest of the
reference material (Flume, etc.) would be a valued addition.


On 10/30/2017 02:20 PM, Matt Sicker wrote:


I could spend an entire blog post about Logstash and ELK in general, so I
feel it's out of scope here.

As for the other questions, I think that's covered by the FAQ <
https://logging.apache.org/log4j/2.x/faq.html>, but if it's not, that
would
be useful here.

On 30 October 2017 at 13:52, Ole Ersoy <ole.er...@gmail.com> wrote:

I thought it was very good.  I'm a big fan of articles that come with and

reference simple examples from a github repository.  One of the most
confusing aspects of Java logging is configuring it to use one provider
when multiple dependencies use different APIs ... SLF4J ... Log4J ... so
if
that were included / referenced I think it would be a plus.  In case you
feel like expanding on the integration with Logstash that would be
awesome
too.  The ELK stack seems to be getting pretty popular.

Cheers,

Ole




On 10/30/2017 01:09 PM, Matt Sicker wrote:

In preparation for an upcoming talk I'll be doing for CJUG, I'm writing a

blog post about introductory concepts to logging from both a developer
and
operator point of view. My current draft is available here: <
https://github.com/jvz/jvz.github.io/blob/logging/_posts/201
7-10-30-logging.md>.
Let me know what you think!

Re: [meta] Draft blog post about logging in general

[Ole Ersoy]

Probably a series of blog posts :).  Another thing that would be great is 
pumping up some of the new features that log4j2 has that developers will love.  
It reads a little bit like a theoretical intro to logging in general (Although 
you did say clearly that that is what it is) and we have a lot of material like 
that, so what is it about the presentation that should make your peers want to 
pay attention?  I'm sure you'll find that even if the audience have heard of 
some of the new log4j2 features, they'll appreciate a recap.  For example 
here's a pretty good article on Kotlin that I recently read:

http://petersommerhoff.com/dev/kotlin/kotlin-for-java-devs/

A specific example of how to log from both a project dependency, as well as the 
core project code, would be great as well.  The FAQ is good, but it feels a 
little bit like reading your Denon Receiver's manual ...

Could be that throwing in Zipkin (http://zipkin.io/) with the rest of the 
reference material (Flume, etc.) would be a valued addition.

On 10/30/2017 02:20 PM, Matt Sicker wrote:

I could spend an entire blog post about Logstash and ELK in general, so I
feel it's out of scope here.

As for the other questions, I think that's covered by the FAQ <
https://logging.apache.org/log4j/2.x/faq.html>, but if it's not, that would
be useful here.

On 30 October 2017 at 13:52, Ole Ersoy <ole.er...@gmail.com> wrote:


I thought it was very good.  I'm a big fan of articles that come with and
reference simple examples from a github repository.  One of the most
confusing aspects of Java logging is configuring it to use one provider
when multiple dependencies use different APIs ... SLF4J ... Log4J ... so if
that were included / referenced I think it would be a plus.  In case you
feel like expanding on the integration with Logstash that would be awesome
too.  The ELK stack seems to be getting pretty popular.

Cheers,

Ole




On 10/30/2017 01:09 PM, Matt Sicker wrote:


In preparation for an upcoming talk I'll be doing for CJUG, I'm writing a
blog post about introductory concepts to logging from both a developer and
operator point of view. My current draft is available here: <
https://github.com/jvz/jvz.github.io/blob/logging/_posts/201
7-10-30-logging.md>.
Let me know what you think!

Re: [meta] Draft blog post about logging in general

[Ole Ersoy]

I thought it was very good.  I'm a big fan of articles that come with and 
reference simple examples from a github repository.  One of the most confusing 
aspects of Java logging is configuring it to use one provider when multiple 
dependencies use different APIs ... SLF4J ... Log4J ... so if that were 
included / referenced I think it would be a plus.  In case you feel like 
expanding on the integration with Logstash that would be awesome too.  The ELK 
stack seems to be getting pretty popular.

Cheers,

Ole



On 10/30/2017 01:09 PM, Matt Sicker wrote:

In preparation for an upcoming talk I'll be doing for CJUG, I'm writing a
blog post about introductory concepts to logging from both a developer and
operator point of view. My current draft is available here: <
https://github.com/jvz/jvz.github.io/blob/logging/_posts/2017-10-30-logging.md>.
Let me know what you think!

Re: Regarding Checkstyle, PMD, and formatting

[Ole Ersoy]

Here's some related material from:

https://www.sitepoint.com/self-documenting-javascript

The take away is to improve code readability by creating variables for boolean 
conditions that are more readable ...
 Exerpt:

Let’s take a look at the example with if clauses again:

|if(!el.offsetWidth || !el.offsetHeight) { } |

Instead of extracting a function, we can also clarify this by introducing a 
variable:

|var isVisible = el.offsetWidth && el.offsetHeight; if(!isVisible) { } |

This can be a better choice than extracting a function — for example, when the 
logic you want to clarify is very specific to a certain algorithm used only in 
one place




On 02/10/2017 01:01 PM, Apache wrote:

Well, smalltalk might be nicer but we code in Java. I prefer to always use 
parens unless all the operators are the same. I’m old so I can never remember 
the precedence order.

Ralph


On Feb 10, 2017, at 11:32 AM, Gary Gregory > wrote:

On Fri, Feb 10, 2017 at 8:07 AM, Matt Sicker>wrote:

The "unnecessary parenthesis" rule is somewhat annoying. While it has good 
intentions, it'll also flag something like this:

foo || (bar && baz)

Sure, && has higher precedence than || (had to look it up just now), but 
who can remember those kinds of rules anyways?


It's one of the many things Smalltalk got right. Left to right, simple as that. 
Different, yes, but simple.

Gary


On 10 February 2017 at 09:36, Remko Popma>wrote:

+1 on braces

On Sat, Feb 11, 2017 at 12:35 AM, Apache>wrote:

You don’t really have to use final everywhere. If you don’t, Gary 
will fix it ;-)

Actually, I really do prefer most of our check style rules, but not 
enough to yell and scream about it. The one that bothers me the most is that I 
want braces wherever they are optional.

Ralph


On Feb 10, 2017, at 8:09 AM, Matt Sicker > wrote:

At work, I've switched from final everywhere to final everywhere 
but local variables while maintaining effective finality instead. I just wish 
Java had final be the default.

On 10 February 2017 at 05:34, Remko Popma>wrote:

Generally agree except that we agreed that the final qualifier 
was optional. This may not be easy (or possible?) to verify automatically 
anyway.

Otherwise all looks reasonable.

Sent from my iPhone

On Feb 10, 2017, at 17:55, Mikael Ståldal > wrote:


Seems reasonable.

On Fri, Feb 10, 2017 at 5:56 AM, Gary Gregory>wrote:

I agree with all that! :-)

Gary


On Feb 9, 2017 7:05 PM, "Matt Sicker" > wrote:

I was browsing through the site and took a look at the 
component reports. Checkstyle alone seems close to pointless as there are over 
200 errors in log4j-api alone. log4j-core has over 2000 errors. Even new files 
that were formatted with our formatter settings such as the CassandraAppender 
plugin have import ordering errors. I also disagree with some of the rules 
configured, but that doesn't really matter when we don't enforce it in the 
first place.

Anyways, what's the point of configuring this and 
adding checkstyle comments yet not even using it? The only project I've come 
across in the wild so far that has checkstyle configured properly was Spring 
Boot, and your pull request has to pass the checkstyle check to even be 
mergeable.

Perhaps if we wish to actually use it, we could loosen 
the rules down to a much smaller set that actually matches the formatter 
settings in src/ide/. If the rules matched our code base, then we could also 
have Jenkins run checkstyle checks which would keep us informed when we mess 
up, and it would also be useful for pull requests (I've had to reformat many 
patches in the past).

Related, there's the style guide 
> which I'm pretty sure I've 
never even looked at before. This could also be normalized with our formatter files. I've 
generally thought of our code style summarized as:

* 4 space indent
* use final
* no star imports outside tests (and those should 
generally be static imports)
* imports should be in some sort of 

Re: Start configuration snippet for log4j2.properties?

[Ole Ersoy]

Incidentally YAML feels more modern and user friendly, but it seems like a lot 
of the current articles focus on the XML format.  I think the YAML support is a 
big plus.  There's a nice comparison of the two formats for log4j2 here:
http://stackoverflow.com/questions/28101903/what-is-a-sample-default-config-file-in-yaml-for-log4j2

Cheers,
Ole


On 07/07/2016 10:22 PM, Ralph Goers wrote:

Remko and I try to answer questions on stackoverflow as quickly as possible.  I 
just responded to yours. But to be honest, you probably could have gotten this 
from the manual online.  All I really did was take the example from the manual 
and tailor it a little bit for use in a Maven build.

Ralph



On Jul 7, 2016, at 7:45 PM, Ole Ersoy <ole.er...@gmail.com 
<mailto:ole.er...@gmail.com>> wrote:

Hi,

Hope it's OK that I ask about this here.  If not just say USER LIST!
http://stackoverflow.com/questions/38254220/start-configuration-snippet-for-log4j2-properties

I think Stackoverflow, given it's QA guidelines and voting features, are a 
great way to speed up adoption and get Log4J2 in front of developers (A lot of 
great java devs listen in on the Qs).  The more information there is WRT to 
specific questions the easier it will be to adopt Log4J2.

Cheers,
Ole

Re: Start configuration snippet for log4j2.properties?

[Ole Ersoy]

Great thanks - good to know.  I usually just grab the source and look at tests, 
but I find it refreshing when the answer is readily available on SO.  SO is 
becoming my cheat sheet :).

Thanks again,
Ole




On 07/07/2016 10:22 PM, Ralph Goers wrote:

Remko and I try to answer questions on stackoverflow as quickly as possible.  I 
just responded to yours. But to be honest, you probably could have gotten this 
from the manual online.  All I really did was take the example from the manual 
and tailor it a little bit for use in a Maven build.

Ralph



On Jul 7, 2016, at 7:45 PM, Ole Ersoy <ole.er...@gmail.com 
<mailto:ole.er...@gmail.com>> wrote:

Hi,

Hope it's OK that I ask about this here.  If not just say USER LIST!
http://stackoverflow.com/questions/38254220/start-configuration-snippet-for-log4j2-properties

I think Stackoverflow, given it's QA guidelines and voting features, are a 
great way to speed up adoption and get Log4J2 in front of developers (A lot of 
great java devs listen in on the Qs).  The more information there is WRT to 
specific questions the easier it will be to adopt Log4J2.

Cheers,
Ole

Start configuration snippet for log4j2.properties?

[Ole Ersoy]

Hi,

Hope it's OK that I ask about this here.  If not just say USER LIST!
http://stackoverflow.com/questions/38254220/start-configuration-snippet-for-log4j2-properties

I think Stackoverflow, given it's QA guidelines and voting features, are a 
great way to speed up adoption and get Log4J2 in front of developers (A lot of 
great java devs listen in on the Qs).  The more information there is WRT to 
specific questions the easier it will be to adopt Log4J2.

Cheers,
Ole

Re: log4j2 evangelism

[Ole Ersoy]

On 07/05/2016 02:04 PM, Matt Sicker wrote:

Oh, I like this idea of a more useful homepage.

Great.  Most of the time all I hear is crickets :)

However, I don't think we can track download statistics all that well as most 
people download it straight from Maven Central.

There's some data here:
https://mvnrepository.com/search?q=log4j2
https://mvnrepository.com/artifact/org.apache.logging.log4j

Also the stats should be available per this:
http://blog.sonatype.com/2010/12/now-available-central-download-statistics-for-oss-projects/

Not sure if access is limited to contributors only ...

Cheers,
Ole




On 5 July 2016 at 12:50, Ole Ersoy <ole.er...@gmail.com 
<mailto:ole.er...@gmail.com>> wrote:

It may help if the performance chart for multiple threads were moved to the 
index page, followed by simple code use and integration steps for other 
libraries.  The front page could be less verbose and more informative / 
executive summary'ish.

When looking for packages on NPM the first thing I look at is downloads 
followed by API use cases.

Here's a superagent example:
https://www.npmjs.com/package/superagent

For log4j2 replace the superagent ferret with the performance chart

Ferret: 50K downloads in the last day (Good)
Log4J2: ?

Ferret: Simple all encompassing API (Good)
Log4J2: ?

Ferret: installation (Very easy)
Log4J2: This is the biggest hangup for people

If it's easy to switch out SLF4J, etc. then that's a big plus.  Maybe just 
one example (Play framework, Spring Boot), followed by links for other 
scenarios.

Ferret: Plugin support - excellent
Log4J2: ?

The current index page sort of has this stuff, but with superagent I get it 
all with a quick glance.

Cheers,
Ole


On 07/04/2016 03:47 PM, Matt Sicker wrote:

We have benchmarks pretty prominently displayed:

https://logging.apache.org/log4j/2.x/performance.html

Also, SLF4J is comparable to log4j-api; both need a logging library to 
actually work such as log4j-core, logback, log4j 1.x, or java.util.logging.

Personally, I've found async logging to be a killer reason to switch due to 
all the performance issues other logging libraries cause.

On 4 July 2016 at 15:33, Ole Ersoy <ole.er...@gmail.com 
<mailto:ole.er...@gmail.com>> wrote:

I personally like log4j 2 a lot (Because of Java 8 lambda support, cleaner 
architecture, etc.) and switching for me was really easy because I use lombok annotations 
to generate the logger.  But what would be the "Killer" reason to upgrade if 
say someone is using SLF4J?  For example HikariCP has this JMH Benchmarking chart on 
their front page that makes a pretty convincing case:
https://github.com/brettwooldridge/HikariCP

Happy 4th,
Ole






On 07/04/2016 02:37 PM, Matt Sicker wrote:

So what sites are best to get syndicated on for this? I get a lot of my 
programming news from various subreddits for instance (r/programming, r/java, 
r/coding) along with Twitter. Otherwise, I learn about new things usually from 
java user groups or online presentations before digging into detailed tutorials 
and books.

On 3 July 2016 at 10:11, Gary Gregory <garydgreg...@gmail.com 
<mailto:garydgreg...@gmail.com>> wrote:


On Jul 2, 2016 4:34 PM, "Remko Popma" <remko.po...@gmail.com 
<mailto:remko.po...@gmail.com>> wrote:
>
>
>
> Sent from my iPhone
>
> On 2016/07/03, at 5:01, Ralph Goers <ralph.go...@dslextreme.com 
<mailto:ralph.go...@dslextreme.com>> wrote:
>
>> Personally, I don’t think talks do all that much. Articles are 
great, but IMO the best route is in trying to get other open source projects to use 
Log4j.
>
> +1

+1

Gary

>
>> Then people who start to use those other projects are forced to 
learn about Log4j.
>>
>> Ralph
>>
>>> On Jul 2, 2016, at 12:15 PM, Matt Sicker <boa...@gmail.com 
<mailto:boa...@gmail.com>> wrote:
>>>
>>> If we could get a talk in to something big like JavaOne, that 
might help adoption, though I have no idea what kind of talks they accept from 
non-Oracle people (if any).
>>>
>>> On 2 July 2016 at 08:57, Remko Popma <remko.po...@gmail.com 
<mailto:remko.po...@gmail.com>> wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Jun 13, 2016 at 11:52 PM, Remko Popma <remko.po...@gmail.com 
<mailto:remko.po...@gmail.com>> wrote:
>>

Re: log4j2 evangelism

[Ole Ersoy]

It may help if the performance chart for multiple threads were moved to the 
index page, followed by simple code use and integration steps for other 
libraries.  The front page could be less verbose and more informative / 
executive summary'ish.

When looking for packages on NPM the first thing I look at is downloads 
followed by API use cases.

Here's a superagent example:
https://www.npmjs.com/package/superagent

For log4j2 replace the superagent ferret with the performance chart

Ferret: 50K downloads in the last day (Good)
Log4J2: ?

Ferret: Simple all encompassing API (Good)
Log4J2: ?

Ferret: installation (Very easy)
Log4J2: This is the biggest hangup for people

If it's easy to switch out SLF4J, etc. then that's a big plus. Maybe just one 
example (Play framework, Spring Boot), followed by links for other scenarios.

Ferret: Plugin support - excellent
Log4J2: ?

The current index page sort of has this stuff, but with superagent I get it all 
with a quick glance.

Cheers,
Ole

On 07/04/2016 03:47 PM, Matt Sicker wrote:

We have benchmarks pretty prominently displayed:

https://logging.apache.org/log4j/2.x/performance.html

Also, SLF4J is comparable to log4j-api; both need a logging library to actually 
work such as log4j-core, logback, log4j 1.x, or java.util.logging.

Personally, I've found async logging to be a killer reason to switch due to all 
the performance issues other logging libraries cause.

On 4 July 2016 at 15:33, Ole Ersoy <ole.er...@gmail.com 
<mailto:ole.er...@gmail.com>> wrote:

I personally like log4j 2 a lot (Because of Java 8 lambda support, cleaner 
architecture, etc.) and switching for me was really easy because I use lombok annotations 
to generate the logger. But what would be the "Killer" reason to upgrade if say 
someone is using SLF4J?  For example HikariCP has this JMH Benchmarking chart on their 
front page that makes a pretty convincing case:
https://github.com/brettwooldridge/HikariCP

Happy 4th,
Ole






On 07/04/2016 02:37 PM, Matt Sicker wrote:

So what sites are best to get syndicated on for this? I get a lot of my 
programming news from various subreddits for instance (r/programming, r/java, 
r/coding) along with Twitter. Otherwise, I learn about new things usually from 
java user groups or online presentations before digging into detailed tutorials 
and books.

On 3 July 2016 at 10:11, Gary Gregory <garydgreg...@gmail.com 
<mailto:garydgreg...@gmail.com>> wrote:


On Jul 2, 2016 4:34 PM, "Remko Popma" <remko.po...@gmail.com 
<mailto:remko.po...@gmail.com>> wrote:
>
>
>
> Sent from my iPhone
>
> On 2016/07/03, at 5:01, Ralph Goers <ralph.go...@dslextreme.com 
<mailto:ralph.go...@dslextreme.com>> wrote:
>
>> Personally, I don’t think talks do all that much. Articles are 
great, but IMO the best route is in trying to get other open source projects to use 
Log4j.
>
> +1

+1

Gary

>
>> Then people who start to use those other projects are forced to 
learn about Log4j.
>>
>> Ralph
>>
>>> On Jul 2, 2016, at 12:15 PM, Matt Sicker <boa...@gmail.com 
<mailto:boa...@gmail.com>> wrote:
>>>
>>> If we could get a talk in to something big like JavaOne, that might 
help adoption, though I have no idea what kind of talks they accept from non-Oracle 
people (if any).
>>>
>>> On 2 July 2016 at 08:57, Remko Popma <remko.po...@gmail.com 
<mailto:remko.po...@gmail.com>> wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Jun 13, 2016 at 11:52 PM, Remko Popma <remko.po...@gmail.com 
<mailto:remko.po...@gmail.com>> wrote:
>>>>>
>>>>> In spite of the fact that Log4j 2 has a very compelling story in 
terms of feature set and performance, I get the impression that adoption is quite slow. I 
could be wrong, but how many open source projects use Log4j 2? Or even how many Apache 
projects?
>>>>>
>>>>> I propose we try to generate some ideas about what we can do to 
increase our uptake. Some things I've been thinking about:
>>>>>
>>>>> * Rewrite the Wikipedia page on Log4j. It's mostly about Log4j 
1.2 and mentions Log4j 2 at the bottom in a footnote. That needs to be the other way around in 
my opinion. The Wikipedia Java logging framework page is even worse.
>>>>> * The Apache Logging site has no explicit mention that Log4j 1 is 
EOL.
>>>>
>>>> I updated the Apache Logging page to mention that Log4j 1 is EOL.
   

Re: log4j2 evangelism

[Ole Ersoy]

I personally like log4j 2 a lot (Because of Java 8 lambda support, cleaner architecture, 
etc.) and switching for me was really easy because I use lombok annotations to generate 
the logger.  But what would be the "Killer" reason to upgrade if say someone is 
using SLF4J?  For example HikariCP has this JMH Benchmarking chart on their front page 
that makes a pretty convincing case:
https://github.com/brettwooldridge/HikariCP

Happy 4th,
Ole





On 07/04/2016 02:37 PM, Matt Sicker wrote:

So what sites are best to get syndicated on for this? I get a lot of my 
programming news from various subreddits for instance (r/programming, r/java, 
r/coding) along with Twitter. Otherwise, I learn about new things usually from 
java user groups or online presentations before digging into detailed tutorials 
and books.

On 3 July 2016 at 10:11, Gary Gregory > wrote:


On Jul 2, 2016 4:34 PM, "Remko Popma" > wrote:
>
>
>
> Sent from my iPhone
>
> On 2016/07/03, at 5:01, Ralph Goers > wrote:
>
>> Personally, I don’t think talks do all that much. Articles are great, 
but IMO the best route is in trying to get other open source projects to use Log4j.
>
> +1

+1

Gary

>
>> Then people who start to use those other projects are forced to learn 
about Log4j.
>>
>> Ralph
>>
>>> On Jul 2, 2016, at 12:15 PM, Matt Sicker > wrote:
>>>
>>> If we could get a talk in to something big like JavaOne, that might 
help adoption, though I have no idea what kind of talks they accept from non-Oracle 
people (if any).
>>>
>>> On 2 July 2016 at 08:57, Remko Popma > wrote:



 On Mon, Jun 13, 2016 at 11:52 PM, Remko Popma > wrote:
>
> In spite of the fact that Log4j 2 has a very compelling story in 
terms of feature set and performance, I get the impression that adoption is quite slow. I 
could be wrong, but how many open source projects use Log4j 2? Or even how many Apache 
projects?
>
> I propose we try to generate some ideas about what we can do to 
increase our uptake. Some things I've been thinking about:
>
> * Rewrite the Wikipedia page on Log4j. It's mostly about Log4j 1.2 
and mentions Log4j 2 at the bottom in a footnote. That needs to be the other way around in my 
opinion. The Wikipedia Java logging framework page is even worse.
> * The Apache Logging site has no explicit mention that Log4j 1 is EOL.

 I updated the Apache Logging page to mention that Log4j 1 is EOL.

>
> * Only the top page on the Log4j 1 site mentions that the project is 
EOL, but it does so in two modest sentences that don't visually stick out and are easily 
ignored. At the very least the download page needs a mention of the EOL and a link to the 
Log4j 2 project, but it may be good to have a notification on every page.

 I added the EOL announcement to the top of all main pages in the Log4j 
1 site.

>
> * Can we get other people involved in evangelizing log4j 2? It would 
be great if we can make more people enthusiastic so they write blog posts or tutorials etc 
about Log4j 2.
> * How can we incentivise people to convert their project to Log4j 2? 
Maybe start a page on Projects Using Log4j 2 and mention people who did the conversion by 
name? Or some other way?
>
> Thoughts?
>
> Remko


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




--
Matt Sicker >

Re: [Feature Request] Setting Log Level at Runtime?

[Ole Ersoy]

Awesome - Thanks guys!  Really loving log4j 2.  In the process of switching 
everything over ATM.  Thanks again,

Ole


On 06/27/2016 07:06 PM, Ralph Goers wrote:

I also provided an answer that provides more information on why Gary’s answer 
is correct and why it is so different.

Ralph


On Jun 27, 2016, at 4:26 PM, Gary Gregory <garydgreg...@gmail.com 
<mailto:garydgreg...@gmail.com>> wrote:

On Mon, Jun 27, 2016 at 3:56 PM, Ole Ersoy <ole.er...@gmail.com 
<mailto:ole.er...@gmail.com>> wrote:

Any chance that the simplicity level for this could could match SLF4J?  I 
think that there is a setLevel method on Logger, but it's protected or private 
...

SLF4J Example:

http://stackoverflow.com/questions/38064066/configuration-a-logger-programmatically-with-log4j-2


 1. // org.apache.logging.log4j.core.config.Configurator;
2.
 3. Configurator.setLevel("com.example.Foo",Level.DEBUG);
4.
 5. // You can also set the root logger:
 6. Configurator.setRootLevel(Level.DEBUG);

I also replied on SO.

Gary



Cheers,
Ole

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org 
<mailto:log4j-dev-unsubscr...@logging.apache.org>
For additional commands, e-mail: log4j-dev-h...@logging.apache.org 
<mailto:log4j-dev-h...@logging.apache.org>




--
E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> | ggreg...@apache.org 
<mailto:ggreg...@apache.org>
Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[Feature Request] Setting Log Level at Runtime?

[Ole Ersoy]

Any chance that the simplicity level for this could could match SLF4J?  I think 
that there is a setLevel method on Logger, but it's protected or private ...

SLF4J Example:
http://stackoverflow.com/questions/38064066/configuration-a-logger-programmatically-with-log4j-2

Cheers,
Ole

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org