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