I think there are two potential issues. One is the breaking change of
the exported package org.apache.sling.commons.log.logback (major version
change). Not sure, about the impact.
The other one is SPIFLy. I agree, requiring it is probably better than
not supporting slf4j 2.x. However, I still think we should try to avoid it.
The only idea that comes to my mind is to do the same as we do with
Apache Felix Jetty. We release two jars, the "normal" one where we embed
jetty and the "light" one which does not. If you choose the light one,
you have to install all the jetty bundles yourself, SPIFly and
potentially other things. On the other hand, it allows you to update
Jetty without waiting for the next Apache Felix Jetty release.
This way we might catch two cookies with one fork.
Regards
Carsten
On 09.01.2025 17:05, Robert Munteanu wrote:
Hi,
Eric has been working on a large PR to move our commons.log bundle to
slf4j 2.0 . I think this is a very welcome improvement.
The only open topic (for me) is the new requirement of using the Aries
SPIFly bundle. Slf4j 2.0 is now using the ServiceLoader mechanism to
discover logging implementations and the OSGi answer to that is SPIFly.
SPIFly is unfortunately heavy on dependencies and will need to be
started very early on for logging to be functional. We have
historically tried to avoid it, for example by creating our Johnzon
wrappers. This might be more important for implementations like sling-
mini.
The details about the requirements start at [1] and I would encorage
anyone that has an idea (or the cycles to implement a solution) to do
so on the PR.
I think supporting slf4j 2.x with the SPIFly requirement is better than
slf4j 1.x without SPIFly, but maybe we can avoid it entirely.
Patches welcome ;-)
Thanks,
Robert
[1]:
https://github.com/apache/sling-org-apache-sling-commons-log/pull/18#issuecomment-2088735403
--
Carsten Ziegeler
Adobe
cziege...@apache.org
