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