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 <ralph.go...@dslextreme.com> wrote: > I agree with most everything you said. Minor quibbles below. > > > On Oct 2, 2023, at 7:19 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > > > Hi Christian, > > > > On Mon, 2 Oct 2023 at 13:13, Christian Grobmeier <c...@grobmeier.de> > 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
