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
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.
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
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
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
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
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
> 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.
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,
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
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,
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
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
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
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
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 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
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
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
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
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
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,
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
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
24 matches
Mail list logo
