Awesome! Happy to help here where I can, although I haven't worked in Java in forever.
Chainsaw is really five parts: - Receivers which grab the data from whatever source - The 'route events to tabs' mechanism - Table/event rendering, including search/filter/colorization and time deltas between events - A hierarchical tree of loggers, which is a quick way to perform logger-level filtering - An expression syntax used by search/filter/colorization The UI has a TON of features which have been added over the years. The receivers are functional but not great (see the xmlreceiver for example). The most useful receiver is VFSLogFilePatternReceiver IMO. Would be great to modernize things a bit, adding support for logstash for example would be handy. The sorting is wonky and slow, especially if sorting times (!) The logic supporting the color/search match bar (to the right of the table) as well as time delta bar (to the left of the table) is overkill and awkward. The color bar is very useful - you can see color and search matches in the entire file at a glance. The time delta bar, not so much. Chainsaw' support for positive and negative filters, combined with colorizing, search and event annotation combine to give you a pretty powerful set of tools for log analysis. It'd take a long time to recreate what's there in another language. Scott On 10/14/17, Matt Sicker <boa...@gmail.com> wrote: > I'm looking at the infra stuff right now. Found this: < > https://issues.apache.org/jira/browse/INFRA-8439>. So it appears we may > already have the webstart code signing thing handled. More info here: < > https://blogs.apache.org/infra/entry/code_signing_service_now_available>. > > On 14 October 2017 at 13:12, Gary Gregory <garydgreg...@gmail.com> wrote: > >> I would really stay away from Java 9 at this point. There is too much >> incompatible tooling out there at this point. I can't even run most apps >> out of the box I have laying around on Java 9 without breakage. >> >> Gary >> >> On Sat, Oct 14, 2017 at 12:09 PM, Matt Sicker <boa...@gmail.com> wrote: >> >> > I forgot to mention my current difficulty in the release process are >> broken >> > tests. I just noticed that my default Java version on this computer is >> > actually 9, not 8, so that could be related. Any guidance from anyone >> who's >> > successfully built this before would be great. >> > >> > On 14 October 2017 at 13:01, Matt Sicker <boa...@gmail.com> wrote: >> > >> > > First off, for some reason, there are two repositories: >> > > >> > > https://github.com/apache/chainsaw >> > > https://github.com/apache/logging-chainsaw >> > > >> > > The second one appears to be up to date. Not sure what to do about >> > > the >> > > first one as it seems to be a relic of when Chainsaw was in SVN. >> > > >> > > Next, bug tracking. The pom says its bugs are tracked in Bugzilla. It >> was >> > > tracked as a component of Log4j 1. See this: <https://bz.apache.org/ >> > > bugzilla/buglist.cgi?bug_status=__open__&component= >> > > chainsaw&product=Log4j%20-%20Now%20in%20Jira>. I believe it would be >> > > useful to switch over to JIRA like we're using for the rest of the >> > logging >> > > projects. Perhaps we can ask infra for some sort of issue transfer if >> > > possible. >> > > >> > > Another issue: the Java source version is set to 1.4. That means it >> > > doesn't even compile using Java 8 due to 1.6 being the oldest source >> > > version usable. That also means that this project hasn't been updated >> to >> > > use generics let alone anything else from the past 13 years (Java 5 >> > > was >> > > released in 2004 back when I was learning how to program in the first >> > > place!). As such, incrementing the base Java version to 1.6 would be >> > > a >> > > minimum change, and I think if we increased to Java 8 or 9 after a >> > release, >> > > that would give us a nice opportunity to do some mechanical >> refactorings >> > > and such which can sometimes be fun. >> > > >> > > Really, though, the choice of Java version or JVM language in general >> for >> > > a modernized version should be determined by whoever is interested in >> > > helping clean everything up and move forward. In that case, since I >> feel >> > a >> > > bit interested here, I'd propose going with either Java 9 or Scala >> > > 2.12 >> > > (Scala provides a neat Swing API wrapper as well). Kotlin could also >> be a >> > > contender here, though I haven't used it much at all yet, so I can't >> > really >> > > make a real recommendation there. There's also the option of >> > > migrating >> > from >> > > Swing to JavaFX if there is interest, though I've never really used >> > JavaFX >> > > before (but have used Swing). >> > > >> > > Then there is the notion of distribution. Since this is a GUI app, >> > > it's >> > > not generally as simple as just publishing to Maven Central. >> > > Naturally, >> > the >> > > standard Apache release process of publishing sources and binaries to >> SVN >> > > works fine, but there are additional options we can consider: >> > > * Publish a Java webstart thing (would require working with infra to >> get >> > > the releases signed; current build instructions tell the user how to >> > create >> > > their own release using a signing key and such) >> > > * Publish a macOS .app bundle. This can be published through our >> > > normal >> > > release channel, but there may also be a way to publish to the Mac >> > > App >> > > Store. Also, a Homebrew formula (or cask) for this would be nice, >> though >> > > they're normally maintained by external package maintainers just like >> in >> > > GNU/Linux distros. >> > > * Publish a native-ish Windows bundle. I don't see anything in the >> build >> > > already, but there are some tools out there to distribute a Java GUI >> app >> > > for Windows that could be useful here. >> > > >> > > I have other ideas I'd like to see such as adding support for the >> > > JSON >> > > layout and future binary layouts (e.g., Avro/Thrift/Protobuf/custom >> > binary >> > > logging format) so there is no reliance on serialized log events or >> > dealing >> > > with ambiguous log files. I'm pretty sure I could come up with a nice >> > > backlog here, and we could try to recruit some interested developers >> > > through helpwanted.a.o and potentially next time we have Google >> > > Summer >> of >> > > Code or other similar hackathon-like things. In general, I always >> > > find >> > the >> > > viewing and searching of logs to be a pain regardless of fancy tools >> like >> > > ELK or Graylog or Splunk, and having a nice local GUI to sort through >> it >> > > all could be super useful, and I'd be interested to see this succeed >> > > in >> > > that. >> > > >> > > With all that in mind, who would be interested in helping out on >> > > this? >> > I'm >> > > having difficulty with the current version getting compiled let alone >> > > getting a release cut, so I'm not even sure how feasible it would be >> > > to >> > cut >> > > a release before going ahead with the next generation. If we start >> > working >> > > on a major version of Chainsaw without a release for the existing >> > > code, >> > > would that need to take place in the incubator, or can we go forward >> > here? >> > > >> > > -- >> > > Matt Sicker <boa...@gmail.com> >> > > >> > >> > >> > >> > -- >> > Matt Sicker <boa...@gmail.com> >> > >> > > > > -- > Matt Sicker <boa...@gmail.com> >
