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