Re: [chainsaw] What is necessary for a 2.2 release?
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 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 >> 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 >>> > 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 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 >>> >> >> 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
Re: [chainsaw] What is necessary for a 2.2 release?
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 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 > 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 >> > 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 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 >> >> >> 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 >> >> >>> >
Re: [chainsaw] What is necessary for a 2.2 release?
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 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
> > 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 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 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
> >> >>> >>
> >> >>> >> wrote:
> >> >>> >>
> >> >>> >>>
> >> >>> >>> On Mon, Oct 2, 2023, at 02:55, Robert Middleton wrote:
> >> >>> Some(most?) of the settings should be saved:
> >> >>>
> >> >>> >>>
> >>
Re: [chainsaw] What is necessary for a 2.2 release?
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
> 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 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 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
>> >>> >>
>> >>> >> 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
>> >>> > >>>
>> >>> 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'
>> >>>
Re: [chainsaw] What is necessary for a 2.2 release?
I started but haven't had much time this week. The UI updates driven by
settings changes are most of what I have left.
On Sun, Oct 8, 2023, 2:17 PM Christian Grobmeier
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 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 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
> >>> >>
> >>> >> 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
> >>> >>>
> >>> 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
Re: [chainsaw] What is necessary for a 2.2 release?
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 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 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
>>> > 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
>>> >>
>>> >> 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
>>> >>
>>> 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
Re: [chainsaw] What is necessary for a 2.2 release?
I think persisting to json format makes sense/would be easy to consume
with tools if needed.
On 10/2/23, Robert Middleton 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 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
>> > 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
>> >>
>> >> 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
>> >
>> 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 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
Re: [chainsaw] What is necessary for a 2.2 release?
> 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 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
> > 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
> >> 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
> 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 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
Re: [chainsaw] What is necessary for a 2.2 release?
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 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
>> 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 >>>
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 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
Re: [chainsaw] What is necessary for a 2.2 release?
On Mon, Oct 2, 2023, at 20:58, Scott Deboy wrote:
> 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.
Of course, I can re-refactor later ;-)
Looking forward to it, feel free to revert whatever you think is
necessary/makes your life easier
>
> Scott
>
> On 10/2/23, Christian Grobmeier 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
>>> 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
> >>> >
> 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 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
Re: [chainsaw] What is necessary for a 2.2 release?
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 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
>> 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
>>> > >> >
>>> > 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 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
Re: [chainsaw] What is necessary for a 2.2 release?
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
> 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 > >
>> > 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 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
Re: [chainsaw] What is necessary for a 2.2 release?
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. -Robert Middleton On Mon, Oct 2, 2023 at 6:12 AM Christian Grobmeier 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 > > > 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 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 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 >
Re: [chainsaw] What is necessary for a 2.2 release?
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 > 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 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 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,
Re: [chainsaw] What is necessary for a 2.2 release?
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. -Robert Middleton On Sun, Oct 1, 2023 at 3:39 PM Christian Grobmeier 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 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 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 > >>> >> > >>> > >> >
Re: [chainsaw] What is necessary for a 2.2 release?
On Sun, Oct 1, 2023, at 22:09, Scott Deboy wrote: > I pushed branch "chainsaw-with-log4j1-dep" representing the working > log4j1 code for those that want to easily see what used to exist. > > I'll probably selectively incorporate pieces from that branch into master. I think thats a great idea. I will be very busy for the next week, so I am not going to make many changes then. However, when I return I plan to work further on the LogPanel and cut it into pieces, so it is (hopefully) easier to maintain. Kind regards, Christian > > On 10/1/23, Christian Grobmeier 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 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 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 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 > >> > >>
Re: [chainsaw] What is necessary for a 2.2 release?
I pushed branch "chainsaw-with-log4j1-dep" representing the working log4j1 code for those that want to easily see what used to exist. I'll probably selectively incorporate pieces from that branch into master. On 10/1/23, Christian Grobmeier 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 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 >>> >>> 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 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 >> >>> >
Re: [chainsaw] What is necessary for a 2.2 release?
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 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 >> 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 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 >>> >> >>> >>
Re: [chainsaw] What is necessary for a 2.2 release?
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. Scott On 10/1/23, Robert Middleton 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 > 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 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 >> >> >> >
Re: [chainsaw] What is necessary for a 2.2 release?
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 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 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 > >> >
Re: [chainsaw] What is necessary for a 2.2 release?
We lost the initial 'Load Chainsaw Configuration' dialog (and menu item) that gave folks a way to set up a Chainsaw configuration. I'd like to see us restore that functionality, along with a menu support. Right now, you have to define a receiver by hand, and it has to be redefined on each app startup because it's not saved. The ability to create a Receiver config from a fileappender definition would help the user experience - that was one of the 'load chainsaw config' features, but may have been specific to log4j1 appender config files. That'd be a great log4j2-supporting feature. Scott On 10/1/23, 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. > > Scott > > On 10/1/23, Christian Grobmeier 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 >> >
Re: [chainsaw] What is necessary for a 2.2 release?
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 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 >>
Re: [chainsaw] What is necessary for a 2.2 release?
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. Scott On 10/1/23, Christian Grobmeier 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 >
[chainsaw] What is necessary for a 2.2 release?
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
