> 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