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