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 t
> 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 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 committer
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 w
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 ca
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
+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.apac
> 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 i
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.
>
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 bei
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 communicat
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
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 a
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
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,
* t
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/reposito
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
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-too
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 RF
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
22 matches
Mail list logo
