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 <[email protected]> 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 > > <[email protected]> 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 > [email protected] >
