I'm working to restore all the menu items that were nuked, and the
prior LogUI/LogPanel functionality allowing config import.
It's a big task, and will likely result in some of the recent
LogUI/LogPanel refactoring being reverted, but will do what I can to
minimize the impact.
Scott
On 10/2/23, 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
>>> >> >>> >>
>>> >> >>>
>>> >> >>
>>> >>
>>>
>
