For the record: - starting with https://github.com/apache/sling-org-apache-sling-starter/commit/31e6d31de2ddbb740b553c9c6775e021b5b1d57b we are using our own Johnzon wrapper, which does not need the SPIFly mediator - the SPIFly mediator is still present as it's needed by the Groovy bundles
Overall a good balance IMO, thanks Carsten for making the changes. Robert On Mon, 2023-11-20 at 15:25 -0800, Eric Norman wrote: > Hi Carsten, > > For me, requiring a service loader mediator isn't a deal breaker. > There > are other parts of my projects that already require it to be there. > The > configuration setup is a one time thing and the runtime overhead > appears to > be insignificant. > > For example, > > 1. Jetty - The "light" classifier of the > org.apache.felix.http.jetty > bundle requires the use of the ServiceLoader to find services > provided by > the various jetty* bundles > 2. SLING-11906 <https://issues.apache.org/jira/browse/SLING-11906> > - > SLF4j 2.x uses the ServiceLoader to locate the logging > implementation. So > any bundles that have migrated to slf4j 2.x (for example logback > 1.3+, tika > 2.5+ and jetty 10+) would require a serviceloader mediator as > well. > > > Regards, > Eric > > On Mon, Nov 20, 2023 at 12:57 AM Carsten Ziegeler > <cziege...@apache.org> > wrote: > > > I think the downside of all of these solutions is that they all > > require > > service loader support - which drags in a lot of other stuff. > > We should try to convince the johnzon community to remove the hard > > requirement on serviceloader - it doesn't really make sense in this > > case. and then we would have an apache, dependency free > > implementation. > > > > To avoid all those dependencies I switched to > > "org.glassfish:jakarta.json:2.0.1" for my projects. Its older, but > > works > > and does not require service loader or anything else at all. > > > > Regards > > Carsten > > > > On 17.11.2023 20:37, Eric Norman wrote: > > > Is the johnzon 2.x implementation better than the parsson library > > > that we > > > are already including in the starter? > > > > > > I've just been switching the geronimo-json_1.0_spec and johnzon- > > > core > > > dependencies to these: > > > > > > <!-- for the jakarta.json APIs --> > > > <dependency> > > > <groupId>jakarta.json</groupId> > > > <artifactId>jakarta.json-api</artifactId> > > > <version>2.1.1</version> > > > <scope>provided</scope> > > > </dependency> > > > > > > <!-- for the jakarta.json implementation used by tests - > > > -> > > > <dependency> > > > <groupId>org.eclipse.parsson</groupId> > > > <artifactId>parsson</artifactId> > > > <version>1.1.1</version> > > > <scope>test</scope> > > > </dependency> > > > > > > Regards, > > > -Eric > > > > > > On Fri, Nov 17, 2023 at 3:03 AM Stefan Seifert > > > <stefan.seif...@diva-e.com.invalid> wrote: > > > > > > > in context of SLING-12058 we are migrating lots of modules from > > javax.json > > > > to jakarta.json. this works fine for modules using javax.json > > > > directly. > > > > > > > > however, we have a few modules which are using johnzon, which > > > > uses > > > > javax.json internally. since version johnzon 1.2.5 (we are > > > > using johnzon > > > > 1.2.21 in latest wrapper bundle) johnzon ships an additional > > > > artifact > > with > > > > classifier "jakarta", which uses jakarta.json internally. both > > > > artifacts > > > > with and without "jakarta" are identical, except the internal > > > > usage of > > the > > > > package name. our wrapper bundle contains the version using > > > > javax.json. > > > > > > > > for non-bundles like maven plugins we can just switch to the > > > > artifact > > with > > > > "jakarta". but this will not work for our bundles. we cannot > > > > ship both > > > > artifacts with and without "jakarta" classifier as wrapper > > > > bundles and > > > > export them both in OSGi with the same version number. i've > > > > found at > > least > > > > one bundle where this is already used (but not released) [1]. > > > > it > > stumbled > > > > about this in PR [2]. the bundles might work anyway as the > > > > bundle > > compiled > > > > against the johnzon "jakarta" affect should also work with the > > javax.json > > > > version at runtime, but this feels like a slippery slope. > > > > > > > > according to [3] johnzon is using a different way starting from > > > > version > > > > 2.0 (which seems to be released a few days ago, although the > > > > homepage is > > > > not updated yet): in version 2.0 johnzon uses only > > > > jakarta.json. > > > > > > > > so it think the correct way is to create and deploy an > > > > additional > > wrapper > > > > bundle for johnzon 2.0, which we can deploy side-by-side with > > > > the old > > > > wrapper bundle with 1.x. i assume we have to support both of > > > > them for > > quite > > > > a time, as there is a lot of code out there using johnzon 1.x. > > > > > > > > WDYT? > > > > > > > > stefan > > > > > > > > [1] > > > > > > https://github.com/apache/sling-org-apache-sling-installer-factory-feature/blob/867bd44f0991cedd130314d833c9aac29ae3f36c/pom.xml#L134-L140 > > > > [2] > > > > https://github.com/apache/sling-org-apache-sling-fsresource/pull/2 > > > > [3] https://johnzon.apache.org/download.html > > > > > > > > > > > -- > > Carsten Ziegeler > > Adobe > > cziege...@apache.org > >
