For the record, I am not saying this change is good or bad. However, no one responded to my feedback which doesn't feel like community consensus to me. No vote was taken, it was just done how Carsten wanted it to be done.
Regards, Eric On Thu, Jan 11, 2024 at 6:10 AM Robert Munteanu <romb...@apache.org> wrote: > 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 > > > > >
