For those of you who didn't see on slack: I did update Chainsaw last
night so you can load/save receivers. That brings Chainsaw back into
a usable state(in my mind at least). I need to check to ensure that
everything gets saved properly, but that shouldn't be too hard.
Scott, would you mind making some issues on github for features that
are needed/were removed? I think one of the biggest problems that I
have seen with Chainsaw before is that there isn't a manual(at least
now somewhat mitigated) and/or a list of features and how to use them,
so I've just been going with what I feel makes the most sense to me.
The one thing that Scott pointed out was the ability to route messages
to tabs; all the plumbing for that should exist for the most part(each
ChainsawReceiver can have 0...N ChainsawEventBatchListener objects).
I'm not sure how best to let the user hook things up - some sort of
visual programming/flow-based view would be very cool but also very
complicated.
-Robert Middleton
On Mon, Oct 9, 2023 at 3:24 PM Christian Grobmeier <grobme...@apache.org> wrote:
>
> On Sun, Oct 8, 2023, at 23:19, Scott Deboy wrote:
> > I started but haven't had much time this week. The UI updates driven by
> > settings changes are most of what I have left.
>
> OK great to hear, in that case I hold myself back a little longer :)
>
> Thanks!
>
> >
> > On Sun, Oct 8, 2023, 2:17 PM Christian Grobmeier <grobme...@apache.org>
> > wrote:
> >
> >> geson seems to do a good job, like Jackson (same JSR).
> >> I'd like to move forward with JSON format for storing properties.
> >>
> >> I am not sure what the status currently is, if Scott is still working on
> >> it :) I could also make some kind of proposal or so for storing properties
> >>
> >> On Tue, Oct 3, 2023, at 01:20, Scott Deboy wrote:
> >> > I think persisting to json format makes sense/would be easy to consume
> >> > with tools if needed.
> >> >
> >> > On 10/2/23, Robert Middleton <rmiddle...@apache.org> wrote:
> >> >>> OK. Do you think something based on Jackson would be good? It's JSON
> >> >>> though.
> >> >>
> >> >> We already have a dependency on genson for JSON parsing, so if we
> >> >> really want to use JSON that would make the most sense. Commons
> >> >> config can read/write XML; currently I just have it configured to do
> >> >> properties files. I think we can write our own reader/writer as well,
> >> >> but ultimately I don't think that there is anything special that we
> >> >> need that commons config doesn't provide us out of the box.
> >> >>
> >> >> -Robert Middleton
> >> >>
> >> >> On Mon, Oct 2, 2023 at 5:14 PM Matt Sicker <m...@musigma.org> wrote:
> >> >>>
> >> >>> Jackson makes for a good library here because it also supports several
> >> >>> data formats (YAML, XML, HOCON, and all sorts of others, both textual
> >> and
> >> >>> binary) and is fairly extensible for hooking any custom serialization
> >> or
> >> >>> deserialization logic you need. Given the desire to avoid Java
> >> >>> serialization, it is perfectly reasonable to avoid XStream as that’s
> >> >>> basically Java serialization using XML with all the pitfalls that
> >> entails
> >> >>> (I dealt with this fairly extensively back in the Jenkins project which
> >> >>> used an old fork of XStream for managing config files and state).
> >> >>>
> >> >>> I haven’t used Commons Configuration before, but it seems fairly
> >> >>> appropriate for this sort of thing as well.
> >> >>>
> >> >>> > On Oct 2, 2023, at 1:43 PM, Christian Grobmeier <
> >> grobme...@apache.org>
> >> >>> > wrote:
> >> >>> >
> >> >>> > On Mon, Oct 2, 2023, at 16:15, Robert Middleton wrote:
> >> >>> >> At least two reasons I can think of:
> >> >>> >> 1. Xstream doesn’t work on all java versions as you saw
> >> >>> >> 2. Simplify by using the commons config instead of rolling our own.
> >> >>> >>
> >> >>> >> Each tab should now have just one config file, the idea being that
> >> you
> >> >>> >> can
> >> >>> >> now share config files between people. Before each tab had at least
> >> >>> >> two(maybe three) files. One was the xml config, one was a java
> >> >>> >> serialized
> >> >>> >> map. Removing the java serialization is important.
> >> >>> >
> >> >>> > OK. Do you think something based on Jackson would be good? It's JSON
> >> >>> > though.
> >> >>> >
> >> >>> > From an example:
> >> >>> >
> >> >>> > ObjectMapper objectMapper = new ObjectMapper();
> >> >>> > Car car = new Car("yellow", "renault");
> >> >>> > objectMapper.writeValue(new File("target/car.json"), car);
> >> >>> >
> >> >>> > We could wrap this in some kind of class and make it accessible per
> >> >>> > "tab" (or whatever).
> >> >>> >
> >> >>> >
> >> >>> >>
> >> >>> >> -Robert Middleton
> >> >>> >>
> >> >>> >> On Mon, Oct 2, 2023 at 6:12 AM Christian Grobmeier
> >> >>> >> <grobme...@apache.org>
> >> >>> >> wrote:
> >> >>> >>
> >> >>> >>>
> >> >>> >>> On Mon, Oct 2, 2023, at 02:55, Robert Middleton wrote:
> >> >>> >>>> Some(most?) of the settings should be saved:
> >> >>> >>>>
> >> >>> >>>
> >> https://github.com/apache/logging-chainsaw/blob/5ccb3c8e55dffd4361c549c3bcdac3f3675f79e5/src/main/java/org/apache/log4j/chainsaw/prefs/SettingsManager.java#L191
> >> >>> >>>>
> >> >>> >>>> The stuff that is commented out should just be the old saving code
> >> >>> >>>> that
> >> >>> >>>> used XStream to save the data out.
> >> >>> >>>
> >> >>> >>> You made it using this commit (thank you, its easy to track):
> >> >>> >>>
> >> >>> >>>
> >> https://github.com/apache/logging-chainsaw/commit/75bedf98665188eef4d13e4bfbb4b0dae456f65e
> >> >>> >>>
> >> >>> >>> One question: why did we remove Xstream? it seem there was an
> >> update
> >> >>> >>> late
> >> >>> >>> 2022 to address some security.
> >> >>> >>> Should we just re-enable it or was there other reasons too?
> >> >>> >>>
> >> >>> >>>
> >> >>> >>>
> >> >>> >>>
> >> >>> >>>>
> >> >>> >>>> -Robert Middleton
> >> >>> >>>>
> >> >>> >>>> On Sun, Oct 1, 2023 at 3:39 PM Christian Grobmeier
> >> >>> >>>> <grobme...@apache.org
> >> >>> >>>>
> >> >>> >>>> wrote:
> >> >>> >>>>
> >> >>> >>>>>
> >> >>> >>>>> On Sun, Oct 1, 2023, at 21:28, Scott Deboy wrote:
> >> >>> >>>>>> The ability to route events to tabs is a core feature in the
> >> code
> >> >>> >>>>>> -
> >> >>> >>>>>> that's how Chainsaw log messages end up in a Chainsaw-specific
> >> tab
> >> >>> >>>>>> -
> >> >>> >>>>>> but the ability to control that routing via a 'routing
> >> expression'
> >> >>> >>>>>> was
> >> >>> >>>>>> nuked from app-wide preferences - another thing we should bring
> >> >>> >>>>>> back.
> >> >>> >>>>>>
> >> >>> >>>>>> It looks like we lost a lot of prefs, both panel-level and
> >> >>> >>>>>> app-wide
> >> >>> >>>>> prefs.
> >> >>> >>>>>
> >> >>> >>>>> Yes, I think all prefs are somehow gone. At least everything that
> >> >>> >>>>> is
> >> >>> >>>>> writes to a file seems to be commented.
> >> >>> >>>>> I didn't remove those things yet, as they seemed to big and I
> >> >>> >>>>> didn't
> >> >>> >>>>> understand well how they'd work or how I would test (I lack the
> >> >>> >>> knowledge
> >> >>> >>>>> of how the UI should operate but only see what is there now)
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>>>
> >> >>> >>>>>> Scott
> >> >>> >>>>>>
> >> >>> >>>>>> On 10/1/23, Robert Middleton <rmiddle...@apache.org> wrote:
> >> >>> >>>>>>> I would say the saving/loading of settings is probably the main
> >> >>> >>> thing to
> >> >>> >>>>>>> fix - if I remember correctly, it kinda works at the moment.
> >> Part
> >> >>> >>>>>>> of
> >> >>> >>>>> the
> >> >>> >>>>>>> issue with what it did before was that the settings were
> >> >>> >>>>>>> scattered
> >> >>> >>> among
> >> >>> >>>>>>> several different files with no apparent rhyme or reason, and
> >> >>> >>> converting
> >> >>> >>>>>>> them to one file I'm not sure if everything works.
> >> >>> >>>>>>>
> >> >>> >>>>>>> The one feature that I'm pretty sure doesn't exist is the
> >> ability
> >> >>> >>>>>>> to
> >> >>> >>>>> have
> >> >>> >>>>>>> multiple log messages go to one tab, but I don't think that is
> >> >>> >>> critical
> >> >>> >>>>> for
> >> >>> >>>>>>> release. In order to properly support that I think requires a
> >> >>> >>>>>>> bit
> >> >>> >>> more
> >> >>> >>>>>>> planning on both the UI side(so you can know how things are
> >> >>> >>>>>>> routed)
> >> >>> >>> and
> >> >>> >>>>> on
> >> >>> >>>>>>> the back-end side(to do the actual routing).
> >> >>> >>>>>>>
> >> >>> >>>>>>> -Robert Middleton
> >> >>> >>>>>>>
> >> >>> >>>>>>> On Sun, Oct 1, 2023 at 3:14 PM Christian Grobmeier <
> >> >>> >>>>> grobme...@apache.org>
> >> >>> >>>>>>> wrote:
> >> >>> >>>>>>>
> >> >>> >>>>>>>> On Sun, Oct 1, 2023, at 20:59, Scott Deboy wrote:
> >> >>> >>>>>>>>> It's great to see the contribution, thanks Christian!
> >> >>> >>>>>>>>>
> >> >>> >>>>>>>>> I pulled down latest master and it looks like there are some
> >> UI
> >> >>> >>>>>>>>> glitches we should fix - for example, resizing the logger
> >> tree
> >> >>> >>> pane
> >> >>> >>>>>>>>> doesn't render correctly.
> >> >>> >>>>>>>>>
> >> >>> >>>>>>>>> As I mentioned before, I assume there are a bunch of features
> >> >>> >>>>>>>>> we
> >> >>> >>> lost
> >> >>> >>>>>>>>> when we moved from log4j1 - some may not be critical, but I
> >> >>> >>>>>>>>> think
> >> >>> >>>>>>>>> persisting 'default' tab settings is pretty important if it's
> >> >>> >>>>>>>>> not
> >> >>> >>>>>>>>>
> >> >>> >>>>>>>>> I'd like us to at least support the log4j2 zeroconf
> >> >>> >>>>>>>>> functionality
> >> >>> >>> as
> >> >>> >>>>>>>>> well as VFSLogFilePatternReceiver.
> >> >>> >>>>>>>>>
> >> >>> >>>>>>>>> I'm happy to dig in - will look at latest master and
> >> >>> >>>>>>>>> contribute.
> >> >>> >>>>>>>>
> >> >>> >>>>>>>> I would be more than glad if you could take some kind of a
> >> lead
> >> >>> >>> here.
> >> >>> >>>>> My
> >> >>> >>>>>>>> Swing-foo is long time gone and so far I just tried to clean a
> >> >>> >>>>>>>> few
> >> >>> >>>>> things
> >> >>> >>>>>>>> or make the code more comprehensible.
> >> >>> >>>>>>>>
> >> >>> >>>>>>>> I will keep trying to extracting things, making classes a bit
> >> >>> >>> smaller
> >> >>> >>>>> if
> >> >>> >>>>>>>> possible. I will closely follow what you are doing and try to
> >> >>> >>>>>>>> learn
> >> >>> >>>>> from
> >> >>> >>>>>>>> it.
> >> >>> >>>>>>>>
> >> >>> >>>>>>>> Maybe, once we can persist tab settings and then release it,
> >> no
> >> >>> >>> matter
> >> >>> >>>>>>>> how
> >> >>> >>>>>>>> the rest of the cleanup is.
> >> >>> >>>>>>>>
> >> >>> >>>>>>>>
> >> >>> >>>>>>>>>
> >> >>> >>>>>>>>> Scott
> >> >>> >>>>>>>>>
> >> >>> >>>>>>>>> On 10/1/23, Christian Grobmeier <grobme...@apache.org>
> >> wrote:
> >> >>> >>>>>>>>>> Hello,
> >> >>> >>>>>>>>>>
> >> >>> >>>>>>>>>> I am moving things around a lot. There is much refactoring
> >> >>> >>>>>>>>>> that
> >> >>> >>> is
> >> >>> >>>>>>>> necessary
> >> >>> >>>>>>>>>> alone LogPanel had ~4500 lines of code. I believe this lot
> >> of
> >> >>> >>> LOCs
> >> >>> >>>>> is
> >> >>> >>>>>>>>>> so
> >> >>> >>>>>>>>>> complicated to understand that it prevents people from
> >> >>> >>> contributing
> >> >>> >>>>> -
> >> >>> >>>>>>>> let
> >> >>> >>>>>>>>>> alone Swing, but we can't change that.
> >> >>> >>>>>>>>>>
> >> >>> >>>>>>>>>> Apart from usual refactorings, I wonder what should be the
> >> >>> >>>>>>>>>> goal
> >> >>> >>> of
> >> >>> >>>>>>>>>> 2.2?
> >> >>> >>>>>>>>>>
> >> >>> >>>>>>>>>> I have already upgraded some dependencies that have security
> >> >>> >>> flaws.
> >> >>> >>>>> 2
> >> >>> >>>>>>>> more
> >> >>> >>>>>>>>>> are in the pom, but they have no patched versions so far.
> >> >>> >>>>>>>>>>
> >> >>> >>>>>>>>>> Should we add at least one feature? Is there maybe one
> >> already
> >> >>> >>>>>>>>>> in
> >> >>> >>>>> that
> >> >>> >>>>>>>>>> I
> >> >>> >>>>>>>>>> missed?
> >> >>> >>>>>>>>>>
> >> >>> >>>>>>>>>> I would appreciate it if one of the more experienced
> >> >>> >>>>>>>>>> Swing-devs
> >> >>> >>> here
> >> >>> >>>>>>>> could
> >> >>> >>>>>>>>>> advise or maybe contribute some code so we can justify a
> >> >>> >>>>>>>>>> release.
> >> >>> >>>>>>>>>>
> >> >>> >>>>>>>>>> The next question would be:
> >> >>> >>>>>>>>>> How is chainsaw released at all?
> >> >>> >>>>>>>>>>
> >> >>> >>>>>>>>>> Kind regards,
> >> >>> >>>>>>>>>> Christian
> >> >>> >>>>>>>>>>
> >> >>> >>>>>>>>
> >> >>> >>>>>>>
> >> >>> >>>>>
> >> >>> >>>
> >> >>>
> >> >>
> >>
