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