Thanks Robert for adding that commit. Does this also mean I can continue with the cleanup? I thought Scott wanted to add something, but I am not sure yet if this was now done by Robert :-)
Please let me know On Fri, Oct 13, 2023, at 22:55, Scott Deboy wrote: > 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 >>> >> >>> >>>>>>>>>> >>> >> >>> >>>>>>>> >>> >> >>> >>>>>>> >>> >> >>> >>>>> >>> >> >>> >>> >>> >> >>> >>> >> >> >>> >> >>