Hey great - yeah I'll go through and add some tickets.
The event routing mechanism is very simple - you define an expression
using the logging event attribute names, and the values in the logging
event are used to convert that expression into a concrete tab name,
where the events are routed.
Note, you can also define 'expression views', like DB views, where an
event matching the expression is added to the expression view tab, but
that's on top of the default routing.
On 10/13/23, Robert Middleton <rmiddle...@apache.org> wrote:
> 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
>> >> >>> >>>>>>>>>>
>> >> >>> >>>>>>>>
>> >> >>> >>>>>>>
>> >> >>> >>>>>
>> >> >>> >>>
>> >> >>>
>> >> >>
>> >>
>
