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