I started but haven't had much time this week. The UI updates driven by
settings changes are most of what I have left.

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

Reply via email to