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: Refining product feature set strategy
On Mon, Oct 2, 2023, at 17:38, Ralph Goers wrote: >>> Agreed. Sandbox could be open even for all ASF committers, entry barriers >>> could be low. Dormant components could go back to sandbox as well, if new >>> people want to work on it. >> >> Can we create a repo open to all Apache committers? If yes, let's >> create a `logging-sandbox` repo right now. > > I don’t believe we can. Commons will make any ASF member a committer if > they ask. I don’t recall if that applies to any ASF committer as well. > It might. I asked Infra, it is possible to create a repository that is public and read/write to all committers Kind regards, Christian
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: Refining product feature set strategy
The JDBC appender is a mission critical component for me. I maintain it whenever something pops up. I even think there is a fix in git 2.x for the next release. There is no way to know reliably who uses what, by design of the whole FOSS ecosystem. Querying the user's mailing list for this type of information is pointless imo. Gary On Mon, Oct 2, 2023, 11:38 AM Ralph Goers wrote: > I agree with most everything you said. Minor quibbles below. > > > On Oct 2, 2023, at 7:19 AM, Piotr P. Karwasz > wrote: > > > > Hi Christian, > > > > On Mon, 2 Oct 2023 at 13:13, Christian Grobmeier > wrote: > >> Sandbox, dormant and stable are not hoops but communication about the > health of a component. > > > > I like this idea. > > > > I think that the main problem we have been debating on this mailing > > list since September is how to communicate to the user, which > > components: > > 1. are actively maintained (a committer works on them), > > 2. are well tested (e.g. have a large user group or a 100% test > coverage). > > > > Modules that fail on both aspects (like `log4j-cassandra`, > > `log4j-couchdb` or `log4j-jeromq`) should be dropped. There is no > > disagreement on that. > > > > On the other hand there are modules that are actively maintained (or > > need no maintenance) and are used by one of our employers. In this > > category we can find `log4j-jdbc*`, `log4j-csv`, `log4j-docker`, > > `log4j-kubernetes` and `log4j-to-jul`. > > > > We should not throw them away, but we need a sign that tells the user: > > * `log4j-docker` has not been used in a long time. The JSON > > configuration it retrieves from Docker might not match the expected > > schema, > > “Has not be used…” - How could anyone know that? In fact, based on the > data I am quite certain there is at least one user. It would be correct to > say it has had no modifications in a while, but that is self evident just > by looking at its git history. > > > * `log4j-jdbc` is rarely used (i.e. tested against a very limited > > number of configurations). If you are not careful, you might have SQL > > injection, > > I don’t know if Gary would agree or not. > > > * `log4j-jndi` uses an old unsecure technology. It requires a > > competent sysadmin to prevent security breaches, > > We now only allow no protocol or java so I don’t think this is an accurate > statement. > > > * ... > > > >> Agreed. Sandbox could be open even for all ASF committers, entry > barriers could be low. Dormant components could go back to sandbox as well, > if new people want to work on it. > > > > Can we create a repo open to all Apache committers? If yes, let's > > create a `logging-sandbox` repo right now. > > I don’t believe we can. Commons will make any ASF member a committer if > they ask. I don’t recall if that applies to any ASF committer as well. It > might. > > Ralph
Re: [VOTE] Release Apache Logging Parent 10.1.1
+1 Yay for the checksum files! > On Oct 2, 2023, at 4:22 AM, Volkan Yazıcı wrote: > > This is a vote to release the Apache Logging Parent 10.1.1. > > Source repository: https://github.com/apache/logging-parent > Commit: 3c28aeba7d19be40b512df2be8e81d80f9a7cd11 > Distribution: https://dist.apache.org/repos/dist/dev/logging/logging-parent > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1188 > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > Please download, test, and cast your votes on this mailing list. > > [ ] +1, release the artifacts > [ ] -1, don't release, because... > > This vote is open for 24 hours and will pass unless getting a > net negative vote count. All votes are welcome and we encourage > everyone to test the release, but only the Logging Services PMC > votes are officially counted. At least 3 +1 votes and more > positive than negative votes are required. > > === Release Notes > > This patch release contains minor fixes addressing issues blocking the > release of `log4j-tools`, `log4j-kotlin`, etc. > > Added > > * Used `project.build.outputTimestamp` to timestamp generated distribution > files > > Changed > > * Changes the default OSGi and module name to use full stops `.` > instead of non-alphanumeric characters > * Update `com.diffplug.spotless:spotless-maven-plugin` to version `2.40.0` > > Fixed > > * Fixed checksum (i.e., `*.sha512`) file format > * Fix BND module name detection on multi-release JARs
Re: Refining product feature set strategy
> On Oct 2, 2023, at 12:04 AM, Volkan Yazıcı wrote: > > I give up. Gut-feeling-driven development FTW. > > Ralph, quoting your own words, "async and gc-free stuff exploded the > complexity of the code base". Yes it did. Matt has refactored the Plugin support at least 3 times and each time it has become more complex. That doesn’t mean it was wrong to do it or it was bad. Likewise with gc-free and async. With some effort we can Improve the situation for those if we choose to. > Plus, we are yet to reproduce Remko's "log4j > is faster than logback" results on a modern stack, where all of our earlier > attempts failed. I never said his results were incorrect. I just said I have never understood how he got them. I couldn’t reproduce them because I never got the full information on how the tests were performed. > Now I find it ironic that you use async/gc-free as an > example to convince me how well our gut-feelings paid off. Umm. Lots of people are doing async logging. I am quite positive that had a beneficial impact on Log4j2. > > All in all, I heard the PMC. We are all converging to a "Ceki Reloaded" > scenario here. I will shut up. 1. I will never encourage you to shut up. 2. I have no idea what you are referring to in regards to Ceki or how anything he has done with his projects relates to this issue. Ralph
Re: Refining product feature set strategy
I agree with most everything you said. Minor quibbles below. > On Oct 2, 2023, at 7:19 AM, Piotr P. Karwasz wrote: > > Hi Christian, > > On Mon, 2 Oct 2023 at 13:13, Christian Grobmeier wrote: >> Sandbox, dormant and stable are not hoops but communication about the health >> of a component. > > I like this idea. > > I think that the main problem we have been debating on this mailing > list since September is how to communicate to the user, which > components: > 1. are actively maintained (a committer works on them), > 2. are well tested (e.g. have a large user group or a 100% test coverage). > > Modules that fail on both aspects (like `log4j-cassandra`, > `log4j-couchdb` or `log4j-jeromq`) should be dropped. There is no > disagreement on that. > > On the other hand there are modules that are actively maintained (or > need no maintenance) and are used by one of our employers. In this > category we can find `log4j-jdbc*`, `log4j-csv`, `log4j-docker`, > `log4j-kubernetes` and `log4j-to-jul`. > > We should not throw them away, but we need a sign that tells the user: > * `log4j-docker` has not been used in a long time. The JSON > configuration it retrieves from Docker might not match the expected > schema, “Has not be used…” - How could anyone know that? In fact, based on the data I am quite certain there is at least one user. It would be correct to say it has had no modifications in a while, but that is self evident just by looking at its git history. > * `log4j-jdbc` is rarely used (i.e. tested against a very limited > number of configurations). If you are not careful, you might have SQL > injection, I don’t know if Gary would agree or not. > * `log4j-jndi` uses an old unsecure technology. It requires a > competent sysadmin to prevent security breaches, We now only allow no protocol or java so I don’t think this is an accurate statement. > * ... > >> Agreed. Sandbox could be open even for all ASF committers, entry barriers >> could be low. Dormant components could go back to sandbox as well, if new >> people want to work on it. > > Can we create a repo open to all Apache committers? If yes, let's > create a `logging-sandbox` repo right now. I don’t believe we can. Commons will make any ASF member a committer if they ask. I don’t recall if that applies to any ASF committer as well. It might. Ralph
Re: [VOTE] Release Apache Log4j Tools 0.5.0
Hi Volkan, On Mon, 2 Oct 2023 at 10:22, Volkan Yazıcı wrote: > Fixed (and tested!) this in `logging-parent`. > We will do a `logging-parent` version `10.1.1` release first. > Consequently issue an RC2 for `-tools` version `0.5.0`. The bug that prevented files with a timestamp equal to 0 from being copied was in `FilteringUtils#copyFile` and the bugged lines were replaced in: https://issues.apache.org/jira/browse/MSHARED-1216 So we have no bug report for Maven. ;-) Piotr
Re: Refining product feature set strategy
Hi Christian, On Mon, 2 Oct 2023 at 13:13, Christian Grobmeier wrote: > Sandbox, dormant and stable are not hoops but communication about the health > of a component. I like this idea. I think that the main problem we have been debating on this mailing list since September is how to communicate to the user, which components: 1. are actively maintained (a committer works on them), 2. are well tested (e.g. have a large user group or a 100% test coverage). Modules that fail on both aspects (like `log4j-cassandra`, `log4j-couchdb` or `log4j-jeromq`) should be dropped. There is no disagreement on that. On the other hand there are modules that are actively maintained (or need no maintenance) and are used by one of our employers. In this category we can find `log4j-jdbc*`, `log4j-csv`, `log4j-docker`, `log4j-kubernetes` and `log4j-to-jul`. We should not throw them away, but we need a sign that tells the user: * `log4j-docker` has not been used in a long time. The JSON configuration it retrieves from Docker might not match the expected schema, * `log4j-jdbc` is rarely used (i.e. tested against a very limited number of configurations). If you are not careful, you might have SQL injection, * `log4j-jndi` uses an old unsecure technology. It requires a competent sysadmin to prevent security breaches, * ... > Agreed. Sandbox could be open even for all ASF committers, entry barriers > could be low. Dormant components could go back to sandbox as well, if new > people want to work on it. Can we create a repo open to all Apache committers? If yes, let's create a `logging-sandbox` repo right now. Piotr
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: Refining product feature set strategy
Hi On Sat, Sep 30, 2023, at 00:52, Ralph Goers wrote: > Requiring hoops that must be jumped through before stuff can be > accepted is just a terrible idea. It does nothing but create a > perception that we are not open to new contributions and new > contributors. I am also against hoops, but all for letting the users know how maintained (or not) a component is. We can accept everything, but first it goes too sandbox. It is the only sand thing to do. Because we didn’t do this, we had log4shell. We accepted a feature long time ago that nobody ever really used and forgot about it. We should at least tell the user what is maintained and what not. Sandbox, dormant and stable are not hoops but communication about the health of a component. > In short, I am in favor of retiring things when they are no longer > maintainable. This is very hard. As you know, I look into chainsaw right now. I believe it is currently not in a good state. It’s hard to read, technology is outdated (swing). Before I started, I would have said it is no longer maintainable. Now I still think the same, but with a lot of effort it could become maintainable again. Even log4j1 could be maintainable with a lot of people power. Following this, nothing would be ever retired. The better metric is: do we have the time to maintain it. If nobody is around who feels responsible a component could go to dormant indicating the state. > I am completely in favor of adding new components when > they make sense. IOW, every contribution needs to be considered on its > own merits. Agreed. Sandbox could be open even for all ASF committers, entry barriers could be low. Dormant components could go back to sandbox as well, if new people want to work on it. Christian > > Ralph > > > >> On Sep 29, 2023, at 11:32 AM, Gary Gregory wrote: >> >> I think Jira is good enough for that, since there is transition from state >> to state that can be used to shepherd issues through. RFC, JEP, all way too >> heavy handed for us IMO. >> >> Gary >> >> >> On Fri, Sep 29, 2023, 2:05 PM Matt Sicker wrote: >> >>> I think it could be valuable for us to establish some form of an RFC >>> process for proposing and developing major new features. I also want to >>> avoid being too process-heavy here as that would also disincentivize >>> contributions. I agree that we should try to be more data-driven to >>> determine what features and products should have the most attention. >>> >>> I do like the idea of having “sample” plugins which are not distributed as >>> binaries, though, which can be used in documentation for examples of how to >>> integrate your own systems. With the flexibility of the plugin system here, >>> we can defer the implementation of more obscure integrations to the end >>> user. >>> >>> I will note that we do already have some level of filtering to what we >>> include. I’ve proposed numerous features in the past that I didn’t pursue >>> due to reasons raised by others or lack of interest. >>> On Sep 29, 2023, at 2:59 AM, Volkan Yazıcı wrote: I want to challenge the current way of PMC determining the product >>> feature set and work towards a more sustainable alternative. Logging Services team... - delivers mission-critical products that are deployed at the core of the world-wide infrastructure (actually, in Mars too) - is short on development resources compared to its wide range of offerings - deals with substantial amount of legacy - suffers from knowledge silo Any IT team in this state would be really conservative on accepting new features and try hard to get rid of the bloat. They would react to this challenge by first discovering the user base, pinpointing the core >>> values, and then lazer-focusing the limited development resources on to the >>> crucial deliverables. Though we do something totally different, one can even say the opposite. Below I share excerpts from recent mailing list posts. *"I had added [X] ... to show how to write plugins and for some consulting-related use cases"* – PMC member explaining how feature X was released *"... stuff seems like it could be useful"* – PMC member asking to keep feature X *"my employer used [X] ... for anyone implementing ... this would be very relevant. By archiving this we are basically telling users that they cannot use it any more since it will no longer be supported. For that reason I am not in favor of [retiring]"* – PMC member asking to keep feature X *"We [the employer] ... use [X]"* – PMC member asking to keep feature X *"User base [is] ... very low to non-existent."* – PMC member asking to keep product X *"[PMC member] has steadfastly [reacted] ... and until he positively says he will no longer maintain it I am not willing to override that"* – PMC
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: [VOTE] Release Apache Logging Parent 10.1.1
Hi Volkan, On Mon, 2 Oct 2023 at 11:22, Volkan Yazıcı wrote: > Please download, test, and cast your votes on this mailing list. > > [ ] +1, release the artifacts > [ ] -1, don't release, because... I tested: * reproducibility from the Git commit, * reproducibility from the source archive, * the timestamp of the files in the archive. Everything checks out: +1 Piotr
[VOTE] Release Apache Logging Parent 10.1.1
This is a vote to release the Apache Logging Parent 10.1.1. Source repository: https://github.com/apache/logging-parent Commit: 3c28aeba7d19be40b512df2be8e81d80f9a7cd11 Distribution: https://dist.apache.org/repos/dist/dev/logging/logging-parent Nexus: https://repository.apache.org/content/repositories/orgapachelogging-1188 Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 Please download, test, and cast your votes on this mailing list. [ ] +1, release the artifacts [ ] -1, don't release, because... This vote is open for 24 hours and will pass unless getting a net negative vote count. All votes are welcome and we encourage everyone to test the release, but only the Logging Services PMC votes are officially counted. At least 3 +1 votes and more positive than negative votes are required. === Release Notes This patch release contains minor fixes addressing issues blocking the release of `log4j-tools`, `log4j-kotlin`, etc. Added * Used `project.build.outputTimestamp` to timestamp generated distribution files Changed * Changes the default OSGi and module name to use full stops `.` instead of non-alphanumeric characters * Update `com.diffplug.spotless:spotless-maven-plugin` to version `2.40.0` Fixed * Fixed checksum (i.e., `*.sha512`) file format * Fix BND module name detection on multi-release JARs
Re: [VOTE] Release Apache Log4j Tools 0.5.0
Fixed (and tested!) this in `logging-parent` to use `project.build.outputTimestamp` instead. Since distribution code is shipped by `logging-parent`, we will do a `logging-parent` version `10.1.1` release first. Consequently issue an RC2 for `-tools` version `0.5.0`. On Sun, Oct 1, 2023 at 4:50 PM Piotr P. Karwasz wrote: > Hi Gary, > > On Sun, 1 Oct 2023 at 14:20, Gary Gregory wrote: > > > > [Note to reviewers: You MUST review a src package, not a git tag.] > > > > -1: Failure running 'mvn clean verify' > > Nice catch. > > The problem comes from the modification date of each file in the > source archive (i.e. start of the epoch). > In this case the Maven Resources Plugin fails to copy > `src/main/resources/log4j-changelog.xsd` to > `target/classes/log4j-changelog.xsd`, because the source modification > date is 0, while the destination modification date is 0 (the file does > not exist). > Granted that this seems like a bug in the Maven Resources Plugin, but > we should fix the modification dates in the archive. > > I am also voting -1. > > Piotr >
Re: [VOTE] Release Apache Log4j Tools 0.5.0
Fixed (and tested!) this in `logging-parent`. We will do a `logging-parent` version `10.1.1` release first. Consequently issue an RC2 for `-tools` version `0.5.0`. On Sun, Oct 1, 2023 at 2:16 PM Gary Gregory wrote: > One day this will work in my fantasy world: > > shasum --check apache-log4j-tools-0.5.0-src.zip.sha512 > shasum: apache-log4j-tools-0.5.0-src.zip.sha512: no properly formatted > SHA checksum lines found > > ;-) > > Gary > > On Fri, Sep 29, 2023 at 5:03 PM Christian Grobmeier > wrote: > > > > +1 > > > > > > > > On Fri, Sep 29, 2023, at 13:13, Volkan Yazıcı wrote: > > > This is a vote to release the Apache Log4j Tools 0.5.0. > > > > > > Source repository: https://github.com/apache/logging-log4j-tools > > > Commit: 861b03c70a76ca19408ffc8c4a77bc0c4e5e4570 > > > Distribution: > https://dist.apache.org/repos/dist/dev/logging/log4j-tools > > > Nexus: > > > > https://repository.apache.org/content/repositories/orgapachelogging-1187 > > > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > > > > > Please download, test, and cast your votes on this mailing list. > > > > > > [ ] +1, release the artifacts > > > [ ] -1, don't release, because... > > > > > > This vote is open for 72 hours and will pass unless getting a > > > net negative vote count. All votes are welcome and we encourage > > > everyone to test the release, but only the Logging Services PMC > > > votes are officially counted. At least 3 +1 votes and more > > > positive than negative votes are required. > > > > > > === Release Notes > > > > > > This minor release contains various bug fixes and improvements. > > > > > > Added > > > > > > * Started publishing the project website[1] > > > > > > [1] https://logging.staged.apache.org/log4j/tools > > > > > > Changed > > > > > > * Made `author` element optional and bumped the XML schema version to > > > `0.1.2` (#81) > > > * Make `log4j-changelog-maven-plugin` thread-safe (#80) > > > * Update `org.apache.logging:logging-parent` to version `10.1.0` (#82) > > > * Update `org.junit.jupiter:junit-jupiter-engine` to version `5.10.0` >
Re: Refining product feature set strategy
I wasn't implying a formal paper work people need to follow. I just wanted to establish a consensus on the discussions of which features to keep/drop should be driven by data. On Fri, Sep 29, 2023 at 8:05 PM Matt Sicker wrote: > I think it could be valuable for us to establish some form of an RFC > process for proposing and developing major new features. I also want to > avoid being too process-heavy here as that would also disincentivize > contributions. I agree that we should try to be more data-driven to > determine what features and products should have the most attention. > > I do like the idea of having “sample” plugins which are not distributed as > binaries, though, which can be used in documentation for examples of how to > integrate your own systems. With the flexibility of the plugin system here, > we can defer the implementation of more obscure integrations to the end > user. > > I will note that we do already have some level of filtering to what we > include. I’ve proposed numerous features in the past that I didn’t pursue > due to reasons raised by others or lack of interest. > > > On Sep 29, 2023, at 2:59 AM, Volkan Yazıcı wrote: > > > > I want to challenge the current way of PMC determining the product > feature > > set and work towards a more sustainable alternative. > > > > Logging Services team... > > > > - delivers mission-critical products that are deployed at the core of > > the world-wide infrastructure (actually, in Mars too) > > - is short on development resources compared to its wide range of > > offerings > > - deals with substantial amount of legacy > > - suffers from knowledge silo > > > > Any IT team in this state would be really conservative on accepting new > > features and try hard to get rid of the bloat. They would react to this > > challenge by first discovering the user base, pinpointing the core > values, > > and then lazer-focusing the limited development resources on to the > crucial > > deliverables. Though we do something totally different, one can even say > > the opposite. Below I share excerpts from recent mailing list posts. > > > > *"I had added [X] ... to show how to write plugins and for some > > consulting-related use cases"* – PMC member explaining how feature X was > > released > > > > *"... stuff seems like it could be useful"* – PMC member asking to keep > > feature X > > > > *"my employer used [X] ... for anyone implementing ... this would be very > > relevant. By archiving this we are basically telling users that they > > cannot use it any more since it will no longer be supported. For that > > reason I am not in favor of [retiring]"* – PMC member asking to keep > > feature X > > > > *"We [the employer] ... use [X]"* – PMC member asking to keep feature X > > > > *"User base [is] ... very low to non-existent."* – PMC member asking to > > keep product X > > > > *"[PMC member] has steadfastly [reacted] ... and until he positively says > > he will no longer maintain it I am not willing to override that"* – PMC > > member asking to keep product X because another (one and only) PMC member > > reacted on product retirement inquiry > > > > *"Our employers are ... paying customers."* – a PMC member explaining why > > we should keep feature X used by an organization employing another PMC > > member > > > > > > I see a pattern in the way we decide to maintain a feature/product: > > > > - It is not data-driven. It is disconnected from its user base. No > usage > > statistics, etc. is shared or used. > > - We serve individuals' and employers' agendas. > > - We underestimate the cost of adding/keeping a feature. > > > > I think this diet is "unhealthy" because: > > > > - It adds up to the bloat. It is yet another component developers need > > to maintain its dependencies, documentation, website, integration with > the > > build system, etc. This bizarrely slows down the development > experience. > > (Ever wondered how much `log4j-osgi` takes during `./mvnw verify`?) > > - It adds up to the attack surface. > > - Features that are supposed to be optional get shipped to users > without > > their consent. (Consider the percentage of the Log4Shell victims that > used > > the JNDI functionality at all.) > > - Scarce development resources get wasted on chores due to the > > excessive landscape. > > - It gives users the wrong impression that the feature/product is > > maintained, though under the hood it is just kept there because a > > privileged group wants so. > > > > I want to refine this approach with your help. To start the discussion, I > > propose the following strategy instead: > > > > *"We only accept a feature with data-driven justification."* – Have a > brand > > new idea? Grab yourself a GitHub/GitLab repository that belongs to either > > you or your employer, knock yourself out without any ASF/PMC burdens, and > > amaze your users. Once the user attraction gets enough gravity, let's > > discuss blessing it
Re: Refining product feature set strategy
I give up. Gut-feeling-driven development FTW. Ralph, quoting your own words, "async and gc-free stuff exploded the complexity of the code base". Plus, we are yet to reproduce Remko's "log4j is faster than logback" results on a modern stack, where all of our earlier attempts failed. Now I find it ironic that you use async/gc-free as an example to convince me how well our gut-feelings paid off. All in all, I heard the PMC. We are all converging to a "Ceki Reloaded" scenario here. I will shut up. On Sat, Sep 30, 2023 at 12:52 AM Ralph Goers wrote: > I’m sorry, I can’t really agree with much of any of this. Following the > thoughts being proposed in this thread much of Log4j 2 and even the initial > work I did to create it would not have seen the light of day. Almost 100% > of the stuff Matt has done would never have happened. > > It is a fact that people come and go from projects. Some stay longer than > others. We have had PMC members who disappeared the day after they were > elected to the PMC. Remko arguably made two of the most significant > contributions in the GC-Free and Async work. Yet he has largely gone > inactive. It happens. Even after accepting the JsonTemplateLayout and > Volkan as a committer we had no guarantee he would stick around. We hoped > he would and he did. Gary and I have each contributed a large number of > components because they met some need we have/had and we continue to > support them. > > Requiring hoops that must be jumped through before stuff can be accepted > is just a terrible idea. It does nothing but create a perception that we > are not open to new contributions and new contributors. > > Yes, we can retire things. I don’t think anyone is arguing against > retiring log4j-cassandra. I haven’t seen any arguments against log4j-kafka. > That is primarily because they are woefully out of date. However, there is > nothing wrong with a module that hasn’t had any updates in a long while if > it is meeting user’s needs. You are never going to know for certain home > many users there are of a given module. That data is impossible to get. Any > company that has their own repository manager (which should be most) will > download a release of an artifact from Maven Central once and it will be > hard for you to know when they did it. The metrics Sonatype provided came > from their security product, which not everyone purchases. Yes, you can > make guesses from those numbers but you can’t actually know how good those > guesses are. > > In short, I am in favor of retiring things when they are no longer > maintainable. I am completely in favor of adding new components when they > make sense. IOW, every contribution needs to be considered on its own > merits. > > Ralph > > > > > On Sep 29, 2023, at 11:32 AM, Gary Gregory > wrote: > > > > I think Jira is good enough for that, since there is transition from > state > > to state that can be used to shepherd issues through. RFC, JEP, all way > too > > heavy handed for us IMO. > > > > Gary > > > > > > On Fri, Sep 29, 2023, 2:05 PM Matt Sicker wrote: > > > >> I think it could be valuable for us to establish some form of an RFC > >> process for proposing and developing major new features. I also want to > >> avoid being too process-heavy here as that would also disincentivize > >> contributions. I agree that we should try to be more data-driven to > >> determine what features and products should have the most attention. > >> > >> I do like the idea of having “sample” plugins which are not distributed > as > >> binaries, though, which can be used in documentation for examples of > how to > >> integrate your own systems. With the flexibility of the plugin system > here, > >> we can defer the implementation of more obscure integrations to the end > >> user. > >> > >> I will note that we do already have some level of filtering to what we > >> include. I’ve proposed numerous features in the past that I didn’t > pursue > >> due to reasons raised by others or lack of interest. > >> > >>> On Sep 29, 2023, at 2:59 AM, Volkan Yazıcı wrote: > >>> > >>> I want to challenge the current way of PMC determining the product > >> feature > >>> set and work towards a more sustainable alternative. > >>> > >>> Logging Services team... > >>> > >>> - delivers mission-critical products that are deployed at the core of > >>> the world-wide infrastructure (actually, in Mars too) > >>> - is short on development resources compared to its wide range of > >>> offerings > >>> - deals with substantial amount of legacy > >>> - suffers from knowledge silo > >>> > >>> Any IT team in this state would be really conservative on accepting new > >>> features and try hard to get rid of the bloat. They would react to this > >>> challenge by first discovering the user base, pinpointing the core > >> values, > >>> and then lazer-focusing the limited development resources on to the > >> crucial > >>> deliverables. Though we do something totally different, one can even > say
