Thanks Robert for adding that commit.
Does this also mean I can continue with the cleanup?
I thought Scott wanted to add something, but I am not sure yet if this was now
done by Robert :-)
Please let me know
On Fri, Oct 13, 2023, at 22:55, Scott Deboy wrote:
> Hey great - yeah I'll go through and add some tickets.
>
> The event routing mechanism is very simple - you define an expression
> using the logging event attribute names, and the values in the logging
> event are used to convert that expression into a concrete tab name,
> where the events are routed.
>
> Note, you can also define 'expression views', like DB views, where an
> event matching the expression is added to the expression view tab, but
> that's on top of the default routing.
>
> On 10/13/23, Robert Middleton <rmiddle...@apache.org> wrote:
>> For those of you who didn't see on slack: I did update Chainsaw last
>> night so you can load/save receivers. That brings Chainsaw back into
>> a usable state(in my mind at least). I need to check to ensure that
>> everything gets saved properly, but that shouldn't be too hard.
>>
>> Scott, would you mind making some issues on github for features that
>> are needed/were removed? I think one of the biggest problems that I
>> have seen with Chainsaw before is that there isn't a manual(at least
>> now somewhat mitigated) and/or a list of features and how to use them,
>> so I've just been going with what I feel makes the most sense to me.
>>
>> The one thing that Scott pointed out was the ability to route messages
>> to tabs; all the plumbing for that should exist for the most part(each
>> ChainsawReceiver can have 0...N ChainsawEventBatchListener objects).
>> I'm not sure how best to let the user hook things up - some sort of
>> visual programming/flow-based view would be very cool but also very
>> complicated.
>>
>> -Robert Middleton
>>
>> On Mon, Oct 9, 2023 at 3:24 PM Christian Grobmeier <grobme...@apache.org>
>> wrote:
>>>
>>> On Sun, Oct 8, 2023, at 23:19, Scott Deboy wrote:
>>> > I started but haven't had much time this week. The UI updates driven by
>>> > settings changes are most of what I have left.
>>>
>>> OK great to hear, in that case I hold myself back a little longer :)
>>>
>>> Thanks!
>>>
>>> >
>>> > On Sun, Oct 8, 2023, 2:17 PM Christian Grobmeier <grobme...@apache.org>
>>> > wrote:
>>> >
>>> >> 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
>>> >> >>> >>>>>>>>>>
>>> >> >>> >>>>>>>>
>>> >> >>> >>>>>>>
>>> >> >>> >>>>>
>>> >> >>> >>>
>>> >> >>>
>>> >> >>
>>> >>
>>
