On 10.01.2025 16:08, Robert Munteanu wrote:
On Fri, 2025-01-10 at 08:51 +0100, Carsten Ziegeler wrote:
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.
No bundles import that package in the Sling Starter. I have found only
one reference in the Sling codebase, in a log webconsole IT [1]. So
probably no concerns in Sling.
Ok, that sounds good.
This assumes that we embed and re-export the SLF4j API as well, right?
This is the one with the unsatisfiable references. I am not familiar
with the ServiceLoader behaviour in OSGi, but I assume that it will
work with resources and classes within a single bundle.
Yes.
This would definitely work, with the slight drawback of needing to
upgrade slf4j and logback. Definitely viable IMO.
Yes. After so many years, one would hope that there is not that much to
be done on logging anymore, but there is always a surprise waiting. As
we now get PRs automatically created when those dependencies change, I
don't think this is a big issue.
I wonder though (I read "too many hacks" in Julian's email ;-) ) if we
could branch off in a different direction and create a bundle that does
the SPIFly's job but in a simple way that is specific for the commons-
log/slf4j situation:
1. Advertise an osgi.serviceloader capability, but restricts its
visiblity via a hook (ResolverHook? [2] ) to only the slf4j api bundle
2. Processes the slf4j api bundle to add an import to the specific
implementation of the ( WeavingHook? [3] )
I don't think this can be done directly in the commons-log bundle
because we'd have a circular dependency between it and the slf4j-api
bundle.
One thing I would like to avoid is weaving :) If we have to do that,
then it might be better to just directly use SPIFLy.
Regards
Carsten
--
Carsten Ziegeler
Adobe
cziege...@apache.org
