Re: Sling Johnzon Wrapper & Jakarta JSON

[Eric Norman]

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  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 
> > -
> >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
> > 
> > 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:
> > > >
> > > >  
> > > >  
> > > >  jakarta.json
> > > >  jakarta.json-api
> > > >  2.1.1
> > > >  provided
> > > >  
> > > >
> > > >   > > Carsten Ziegeler
> > > Adobe
> > > cziege...@apache.org
> > >
>
>

Re: Sling Johnzon Wrapper & Jakarta JSON

[Robert Munteanu]

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 
> -
>    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
> 
> 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:
> > > 
> > >  
> > >  
> > >  jakarta.json
> > >  jakarta.json-api
> > >  2.1.1
> > >  provided
> > >  
> > > 
> > >   > Carsten Ziegeler
> > Adobe
> > cziege...@apache.org
> > 

Re: Sling Johnzon Wrapper & Jakarta JSON

[Eric Norman]

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  -
   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 
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:
> >
> >  
> >  
> >  jakarta.json
> >  jakarta.json-api
> >  2.1.1
> >  provided
> >  
> >
> >  
> >  
> >  org.eclipse.parsson
> >  parsson
> >  1.1.1
> >  test
> >  
> >
> > Regards,
> > -Eric
> >
> > On Fri, Nov 17, 2023 at 3:03 AM Stefan Seifert
> >  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
>

Re: Sling Johnzon Wrapper & Jakarta JSON

[Carsten Ziegeler]

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:

 
 
 jakarta.json
 jakarta.json-api
 2.1.1
 provided
 

 
 
 org.eclipse.parsson
 parsson
 1.1.1
 test
 

Regards,
-Eric

On Fri, Nov 17, 2023 at 3:03 AM Stefan Seifert
 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

Re: Sling Johnzon Wrapper & Jakarta JSON

[Eric Norman]

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:



jakarta.json
jakarta.json-api
2.1.1
provided




org.eclipse.parsson
parsson
1.1.1
test


Regards,
-Eric

On Fri, Nov 17, 2023 at 3:03 AM Stefan Seifert
 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
>