Johnzon JSON-B on OSGi

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Johnzon JSON-B on OSGi

maggu2810
Hi,

I posted my problem already to the Johnzon mailing list and have been
told to ask the Karaf team. So please let me ask you (this should be
no cross posting).
See: https://lists.apache.org/thread.html/b2134d2002738d33a57a329966ef38563372613502947158358092fa@%3Cdev.johnzon.apache.org%3E

I am not really sure if Karaf is using Johnzon. The current master
source tree only finds the usage of johnzon-core and johnzon-mapper on
an camel demo / example and it uses a rather old version (0.95).
But as you "know" a lot of OSGi bundles you perhaps know which one
satisfy the respective requirements.

Let me repeat the description of my problem:

I would like to use johnzon-jsonb 1.1.12 in an OSGi container.

After adding johnzon-jsonb I got:
osgi.wiring.package: (&(osgi.wiring.package=javax.json.bind))

That's easy, we need the respective API bundle.
I added org.apache.geronimo.specs/geronimo-jsonb_1.0_spec/1.1

johnzon-jsonb requires: osgi.contract: (&(osgi.contract=JavaCDI)(version=2.0.0))
I added org.apache.geronimo.specs/geronimo-jcdi_2.0_spec/1.1
This bundle provides the JavaCDI contract version 2.0.0

The jcdi bundle requires: osgi.wiring.package: (&(osgi.wiring.package=javax.el))
I added org.apache.geronimo.specs/geronimo-el_2.2_spec/1.1

The jcdi also requires: osgi.wiring.package:
(&(osgi.wiring.package=javax.inject))
I added org.apache.geronimo.specs/geronimo-atinject_1.0_spec/1.1

The jcdi also requires: osgi.serviceloader:
(osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)

I don't know which bundle provides that service loader.

Can you please point me to a set of bundles to use Johnzon JSON-B in OSGi?

With regards,
Markus
Reply | Threaded
Open this post in threaded view
|

Re: Johnzon JSON-B on OSGi

jbonofre
First, you can also embed Johnzon as private package in your bundle,
that's probably the easiest way.

All is not necessary bundle and import in OSGi ! I don't understand why
the users systematically wants bundles/imports for everything ;)

Anyway, can you share exactly the message ? The missing is not a bundle,
it's a capability (service.loader). It's something you can add in a
feature for instance.

What I propose to you is to create a features for that.

Regards
JB

On 15/09/2019 12:20, Markus Rathgeb wrote:

> Hi,
>
> I posted my problem already to the Johnzon mailing list and have been
> told to ask the Karaf team. So please let me ask you (this should be
> no cross posting).
> See: https://lists.apache.org/thread.html/b2134d2002738d33a57a329966ef38563372613502947158358092fa@%3Cdev.johnzon.apache.org%3E
>
> I am not really sure if Karaf is using Johnzon. The current master
> source tree only finds the usage of johnzon-core and johnzon-mapper on
> an camel demo / example and it uses a rather old version (0.95).
> But as you "know" a lot of OSGi bundles you perhaps know which one
> satisfy the respective requirements.
>
> Let me repeat the description of my problem:
>
> I would like to use johnzon-jsonb 1.1.12 in an OSGi container.
>
> After adding johnzon-jsonb I got:
> osgi.wiring.package: (&(osgi.wiring.package=javax.json.bind))
>
> That's easy, we need the respective API bundle.
> I added org.apache.geronimo.specs/geronimo-jsonb_1.0_spec/1.1
>
> johnzon-jsonb requires: osgi.contract: (&(osgi.contract=JavaCDI)(version=2.0.0))
> I added org.apache.geronimo.specs/geronimo-jcdi_2.0_spec/1.1
> This bundle provides the JavaCDI contract version 2.0.0
>
> The jcdi bundle requires: osgi.wiring.package: (&(osgi.wiring.package=javax.el))
> I added org.apache.geronimo.specs/geronimo-el_2.2_spec/1.1
>
> The jcdi also requires: osgi.wiring.package:
> (&(osgi.wiring.package=javax.inject))
> I added org.apache.geronimo.specs/geronimo-atinject_1.0_spec/1.1
>
> The jcdi also requires: osgi.serviceloader:
> (osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)
>
> I don't know which bundle provides that service loader.
>
> Can you please point me to a set of bundles to use Johnzon JSON-B in OSGi?
>
> With regards,
> Markus
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Johnzon JSON-B on OSGi

maggu2810
Hi JB,

thanks for your reply.

About your comment that you don't understand why people would like to
use OSGi bundles if possible instead of import stuff into private
packages:

Isn't one thing we prefer in OSGi that we program / compile against an
API instead of a specific implementation?
I would like to move from Jackson, Gson, Johnzon Mapper usage (hard
dependency because using that specific implementation) to JSON-P
(JSR-353) and JSON-B (JSR-367).
Doesn't it make sense (for you) to such an official standard?

After more and more bundles (of mine) will be migrated to e.g. JSON-B
I would like to use JSON-B in my OSGi environments easily.
Just state that there must be such an implementation available at runtime.

Is this wrong?
Isn't that exactly what has been chosen for the reference
implementation of the Configurator by Apache Felix?
They didn't embed an JSON-P implementation in the configurator bundle
but an implementation of our choose can be used at runtime.

johnzon-jsonb already contains the OSGi related headers in its
manifest I just want to get it working.
I already created a fake bundle that just tell the runtime it would
provide the requested capability (without providing it).
This works at the moment as it seems no-one really needs the requested
capabilities.
(I have to use a bundle instead of a feature because it should work in
Karaf and inside any other OSGi runtime that does not know about Karaf
specific stuff e.g. features).

Wouldn't it be better to get / "know" the correct bundle set to get it
working and perhaps create some PRs to get it working everywhere
instead of fixing it downstream on my side only?

I will provide the specific messages later.
AFAIK servicemix already provides some API bundles (for other APIs)
that differ between the plain API bundles as the servicemix ones
contains a serviceloader and that manifest entries.

Best regards,
Markus

Am So., 15. Sept. 2019 um 19:19 Uhr schrieb Jean-Baptiste Onofré
<[hidden email]>:

>
> First, you can also embed Johnzon as private package in your bundle,
> that's probably the easiest way.
>
> All is not necessary bundle and import in OSGi ! I don't understand why
> the users systematically wants bundles/imports for everything ;)
>
> Anyway, can you share exactly the message ? The missing is not a bundle,
> it's a capability (service.loader). It's something you can add in a
> feature for instance.
>
> What I propose to you is to create a features for that.
>
> Regards
> JB
>
> On 15/09/2019 12:20, Markus Rathgeb wrote:
> > Hi,
> >
> > I posted my problem already to the Johnzon mailing list and have been
> > told to ask the Karaf team. So please let me ask you (this should be
> > no cross posting).
> > See: https://lists.apache.org/thread.html/b2134d2002738d33a57a329966ef38563372613502947158358092fa@%3Cdev.johnzon.apache.org%3E
> >
> > I am not really sure if Karaf is using Johnzon. The current master
> > source tree only finds the usage of johnzon-core and johnzon-mapper on
> > an camel demo / example and it uses a rather old version (0.95).
> > But as you "know" a lot of OSGi bundles you perhaps know which one
> > satisfy the respective requirements.
> >
> > Let me repeat the description of my problem:
> >
> > I would like to use johnzon-jsonb 1.1.12 in an OSGi container.
> >
> > After adding johnzon-jsonb I got:
> > osgi.wiring.package: (&(osgi.wiring.package=javax.json.bind))
> >
> > That's easy, we need the respective API bundle.
> > I added org.apache.geronimo.specs/geronimo-jsonb_1.0_spec/1.1
> >
> > johnzon-jsonb requires: osgi.contract: (&(osgi.contract=JavaCDI)(version=2.0.0))
> > I added org.apache.geronimo.specs/geronimo-jcdi_2.0_spec/1.1
> > This bundle provides the JavaCDI contract version 2.0.0
> >
> > The jcdi bundle requires: osgi.wiring.package: (&(osgi.wiring.package=javax.el))
> > I added org.apache.geronimo.specs/geronimo-el_2.2_spec/1.1
> >
> > The jcdi also requires: osgi.wiring.package:
> > (&(osgi.wiring.package=javax.inject))
> > I added org.apache.geronimo.specs/geronimo-atinject_1.0_spec/1.1
> >
> > The jcdi also requires: osgi.serviceloader:
> > (osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)
> >
> > I don't know which bundle provides that service loader.
> >
> > Can you please point me to a set of bundles to use Johnzon JSON-B in OSGi?
> >
> > With regards,
> > Markus
> >
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Johnzon JSON-B on OSGi

jbonofre
Hi,

there's a difference between an API used externally and an impl used
"internally".

JSON-B as API makes sense (with service), and that should be exported
and imported by other bundles. However, the JSON-B impl using Johnzon
can embed Johnzon as private and just expose JSON-B service.
That's actually better IMHO as you hide the implementation details from
the API.
That's the purpose of OSGi IMHO.

Back on your question about the capability, I agree with you: it's
better to have bundle providing the capability if other bundles need it.
The question is why "client" bundles have a requirement not already
provided or existing.

We already did some "wrapped" bundles (for instance Aries JAXRS API) in
such case.
More than a bundle, it's maybe better to evaluate to provide such
capability at feature level.

Regards
JB

On 16/09/2019 07:00, Markus Rathgeb wrote:

> Hi JB,
>
> thanks for your reply.
>
> About your comment that you don't understand why people would like to
> use OSGi bundles if possible instead of import stuff into private
> packages:
>
> Isn't one thing we prefer in OSGi that we program / compile against an
> API instead of a specific implementation?
> I would like to move from Jackson, Gson, Johnzon Mapper usage (hard
> dependency because using that specific implementation) to JSON-P
> (JSR-353) and JSON-B (JSR-367).
> Doesn't it make sense (for you) to such an official standard?
>
> After more and more bundles (of mine) will be migrated to e.g. JSON-B
> I would like to use JSON-B in my OSGi environments easily.
> Just state that there must be such an implementation available at runtime.
>
> Is this wrong?
> Isn't that exactly what has been chosen for the reference
> implementation of the Configurator by Apache Felix?
> They didn't embed an JSON-P implementation in the configurator bundle
> but an implementation of our choose can be used at runtime.
>
> johnzon-jsonb already contains the OSGi related headers in its
> manifest I just want to get it working.
> I already created a fake bundle that just tell the runtime it would
> provide the requested capability (without providing it).
> This works at the moment as it seems no-one really needs the requested
> capabilities.
> (I have to use a bundle instead of a feature because it should work in
> Karaf and inside any other OSGi runtime that does not know about Karaf
> specific stuff e.g. features).
>
> Wouldn't it be better to get / "know" the correct bundle set to get it
> working and perhaps create some PRs to get it working everywhere
> instead of fixing it downstream on my side only?
>
> I will provide the specific messages later.
> AFAIK servicemix already provides some API bundles (for other APIs)
> that differ between the plain API bundles as the servicemix ones
> contains a serviceloader and that manifest entries.
>
> Best regards,
> Markus
>
> Am So., 15. Sept. 2019 um 19:19 Uhr schrieb Jean-Baptiste Onofré
> <[hidden email]>:
>>
>> First, you can also embed Johnzon as private package in your bundle,
>> that's probably the easiest way.
>>
>> All is not necessary bundle and import in OSGi ! I don't understand why
>> the users systematically wants bundles/imports for everything ;)
>>
>> Anyway, can you share exactly the message ? The missing is not a bundle,
>> it's a capability (service.loader). It's something you can add in a
>> feature for instance.
>>
>> What I propose to you is to create a features for that.
>>
>> Regards
>> JB
>>
>> On 15/09/2019 12:20, Markus Rathgeb wrote:
>>> Hi,
>>>
>>> I posted my problem already to the Johnzon mailing list and have been
>>> told to ask the Karaf team. So please let me ask you (this should be
>>> no cross posting).
>>> See: https://lists.apache.org/thread.html/b2134d2002738d33a57a329966ef38563372613502947158358092fa@%3Cdev.johnzon.apache.org%3E
>>>
>>> I am not really sure if Karaf is using Johnzon. The current master
>>> source tree only finds the usage of johnzon-core and johnzon-mapper on
>>> an camel demo / example and it uses a rather old version (0.95).
>>> But as you "know" a lot of OSGi bundles you perhaps know which one
>>> satisfy the respective requirements.
>>>
>>> Let me repeat the description of my problem:
>>>
>>> I would like to use johnzon-jsonb 1.1.12 in an OSGi container.
>>>
>>> After adding johnzon-jsonb I got:
>>> osgi.wiring.package: (&(osgi.wiring.package=javax.json.bind))
>>>
>>> That's easy, we need the respective API bundle.
>>> I added org.apache.geronimo.specs/geronimo-jsonb_1.0_spec/1.1
>>>
>>> johnzon-jsonb requires: osgi.contract: (&(osgi.contract=JavaCDI)(version=2.0.0))
>>> I added org.apache.geronimo.specs/geronimo-jcdi_2.0_spec/1.1
>>> This bundle provides the JavaCDI contract version 2.0.0
>>>
>>> The jcdi bundle requires: osgi.wiring.package: (&(osgi.wiring.package=javax.el))
>>> I added org.apache.geronimo.specs/geronimo-el_2.2_spec/1.1
>>>
>>> The jcdi also requires: osgi.wiring.package:
>>> (&(osgi.wiring.package=javax.inject))
>>> I added org.apache.geronimo.specs/geronimo-atinject_1.0_spec/1.1
>>>
>>> The jcdi also requires: osgi.serviceloader:
>>> (osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)
>>>
>>> I don't know which bundle provides that service loader.
>>>
>>> Can you please point me to a set of bundles to use Johnzon JSON-B in OSGi?
>>>
>>> With regards,
>>> Markus
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> [hidden email]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Johnzon JSON-B on OSGi

maggu2810
Hi,

> However, the JSON-B impl using Johnzon
> can embed Johnzon as private and just expose JSON-B service.
> That's actually better IMHO as you hide the implementation details from
> the API.
> That's the purpose of OSGi IMHO.

From my understanding this is exactly what johnzon-jsonb should provide:
"Johnzon provides a module johnzon-jsonb implementing JSON-B standard
based on Johnzon Mapper."

johnzon-josnb uses internally the johnzon-mapper implementation to
provide that functionality by the JSON-B API.

I just want to use the JSON-B API in all my implementations and use
johnzon-jsonb as a bundle that provides a JSON-B implementation (the
fact that Johnzon [Mapper] is used I don't really care about).
johnzon-jsonb an OSGi manifest so I would like to get it running ;)

> The question is why "client" bundles have a requirement not already
> provided or existing.

Good question, I don't know.
My assumption has been, that the bundle exists that provides the
required capabilities, I just don't find them.
So my request: Does anyone know about the bundle(s) that provide the
capabilities.

I will post the required capas soon (if I am back on my working machine).

Best regards,
Markus

>
> We already did some "wrapped" bundles (for instance Aries JAXRS API) in
> such case.
> More than a bundle, it's maybe better to evaluate to provide such
> capability at feature level.
>
> Regards
> JB
>
> On 16/09/2019 07:00, Markus Rathgeb wrote:
> > Hi JB,
> >
> > thanks for your reply.
> >
> > About your comment that you don't understand why people would like to
> > use OSGi bundles if possible instead of import stuff into private
> > packages:
> >
> > Isn't one thing we prefer in OSGi that we program / compile against an
> > API instead of a specific implementation?
> > I would like to move from Jackson, Gson, Johnzon Mapper usage (hard
> > dependency because using that specific implementation) to JSON-P
> > (JSR-353) and JSON-B (JSR-367).
> > Doesn't it make sense (for you) to such an official standard?
> >
> > After more and more bundles (of mine) will be migrated to e.g. JSON-B
> > I would like to use JSON-B in my OSGi environments easily.
> > Just state that there must be such an implementation available at runtime.
> >
> > Is this wrong?
> > Isn't that exactly what has been chosen for the reference
> > implementation of the Configurator by Apache Felix?
> > They didn't embed an JSON-P implementation in the configurator bundle
> > but an implementation of our choose can be used at runtime.
> >
> > johnzon-jsonb already contains the OSGi related headers in its
> > manifest I just want to get it working.
> > I already created a fake bundle that just tell the runtime it would
> > provide the requested capability (without providing it).
> > This works at the moment as it seems no-one really needs the requested
> > capabilities.
> > (I have to use a bundle instead of a feature because it should work in
> > Karaf and inside any other OSGi runtime that does not know about Karaf
> > specific stuff e.g. features).
> >
> > Wouldn't it be better to get / "know" the correct bundle set to get it
> > working and perhaps create some PRs to get it working everywhere
> > instead of fixing it downstream on my side only?
> >
> > I will provide the specific messages later.
> > AFAIK servicemix already provides some API bundles (for other APIs)
> > that differ between the plain API bundles as the servicemix ones
> > contains a serviceloader and that manifest entries.
> >
> > Best regards,
> > Markus
> >
> > Am So., 15. Sept. 2019 um 19:19 Uhr schrieb Jean-Baptiste Onofré
> > <[hidden email]>:
> >>
> >> First, you can also embed Johnzon as private package in your bundle,
> >> that's probably the easiest way.
> >>
> >> All is not necessary bundle and import in OSGi ! I don't understand why
> >> the users systematically wants bundles/imports for everything ;)
> >>
> >> Anyway, can you share exactly the message ? The missing is not a bundle,
> >> it's a capability (service.loader). It's something you can add in a
> >> feature for instance.
> >>
> >> What I propose to you is to create a features for that.
> >>
> >> Regards
> >> JB
> >>
> >> On 15/09/2019 12:20, Markus Rathgeb wrote:
> >>> Hi,
> >>>
> >>> I posted my problem already to the Johnzon mailing list and have been
> >>> told to ask the Karaf team. So please let me ask you (this should be
> >>> no cross posting).
> >>> See: https://lists.apache.org/thread.html/b2134d2002738d33a57a329966ef38563372613502947158358092fa@%3Cdev.johnzon.apache.org%3E
> >>>
> >>> I am not really sure if Karaf is using Johnzon. The current master
> >>> source tree only finds the usage of johnzon-core and johnzon-mapper on
> >>> an camel demo / example and it uses a rather old version (0.95).
> >>> But as you "know" a lot of OSGi bundles you perhaps know which one
> >>> satisfy the respective requirements.
> >>>
> >>> Let me repeat the description of my problem:
> >>>
> >>> I would like to use johnzon-jsonb 1.1.12 in an OSGi container.
> >>>
> >>> After adding johnzon-jsonb I got:
> >>> osgi.wiring.package: (&(osgi.wiring.package=javax.json.bind))
> >>>
> >>> That's easy, we need the respective API bundle.
> >>> I added org.apache.geronimo.specs/geronimo-jsonb_1.0_spec/1.1
> >>>
> >>> johnzon-jsonb requires: osgi.contract: (&(osgi.contract=JavaCDI)(version=2.0.0))
> >>> I added org.apache.geronimo.specs/geronimo-jcdi_2.0_spec/1.1
> >>> This bundle provides the JavaCDI contract version 2.0.0
> >>>
> >>> The jcdi bundle requires: osgi.wiring.package: (&(osgi.wiring.package=javax.el))
> >>> I added org.apache.geronimo.specs/geronimo-el_2.2_spec/1.1
> >>>
> >>> The jcdi also requires: osgi.wiring.package:
> >>> (&(osgi.wiring.package=javax.inject))
> >>> I added org.apache.geronimo.specs/geronimo-atinject_1.0_spec/1.1
> >>>
> >>> The jcdi also requires: osgi.serviceloader:
> >>> (osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)
> >>>
> >>> I don't know which bundle provides that service loader.
> >>>
> >>> Can you please point me to a set of bundles to use Johnzon JSON-B in OSGi?
> >>>
> >>> With regards,
> >>> Markus
> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> [hidden email]
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Johnzon JSON-B on OSGi

jbonofre
That's exactly my point: johnzon-jsonb should not expose johnzon
packages at all.

Back on cap, for service loader, the SPI bundle should provide it:

https://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html

So, if johnzon-jsonb doesn't provide, it's a mistake in this bundle IMHO.

Regards
JB

On 16/09/2019 07:43, Markus Rathgeb wrote:

> Hi,
>
>> However, the JSON-B impl using Johnzon
>> can embed Johnzon as private and just expose JSON-B service.
>> That's actually better IMHO as you hide the implementation details from
>> the API.
>> That's the purpose of OSGi IMHO.
>
> From my understanding this is exactly what johnzon-jsonb should provide:
> "Johnzon provides a module johnzon-jsonb implementing JSON-B standard
> based on Johnzon Mapper."
>
> johnzon-josnb uses internally the johnzon-mapper implementation to
> provide that functionality by the JSON-B API.
>
> I just want to use the JSON-B API in all my implementations and use
> johnzon-jsonb as a bundle that provides a JSON-B implementation (the
> fact that Johnzon [Mapper] is used I don't really care about).
> johnzon-jsonb an OSGi manifest so I would like to get it running ;)
>
>> The question is why "client" bundles have a requirement not already
>> provided or existing.
>
> Good question, I don't know.
> My assumption has been, that the bundle exists that provides the
> required capabilities, I just don't find them.
> So my request: Does anyone know about the bundle(s) that provide the
> capabilities.
>
> I will post the required capas soon (if I am back on my working machine).
>
> Best regards,
> Markus
>
>>
>> We already did some "wrapped" bundles (for instance Aries JAXRS API) in
>> such case.
>> More than a bundle, it's maybe better to evaluate to provide such
>> capability at feature level.
>>
>> Regards
>> JB
>>
>> On 16/09/2019 07:00, Markus Rathgeb wrote:
>>> Hi JB,
>>>
>>> thanks for your reply.
>>>
>>> About your comment that you don't understand why people would like to
>>> use OSGi bundles if possible instead of import stuff into private
>>> packages:
>>>
>>> Isn't one thing we prefer in OSGi that we program / compile against an
>>> API instead of a specific implementation?
>>> I would like to move from Jackson, Gson, Johnzon Mapper usage (hard
>>> dependency because using that specific implementation) to JSON-P
>>> (JSR-353) and JSON-B (JSR-367).
>>> Doesn't it make sense (for you) to such an official standard?
>>>
>>> After more and more bundles (of mine) will be migrated to e.g. JSON-B
>>> I would like to use JSON-B in my OSGi environments easily.
>>> Just state that there must be such an implementation available at runtime.
>>>
>>> Is this wrong?
>>> Isn't that exactly what has been chosen for the reference
>>> implementation of the Configurator by Apache Felix?
>>> They didn't embed an JSON-P implementation in the configurator bundle
>>> but an implementation of our choose can be used at runtime.
>>>
>>> johnzon-jsonb already contains the OSGi related headers in its
>>> manifest I just want to get it working.
>>> I already created a fake bundle that just tell the runtime it would
>>> provide the requested capability (without providing it).
>>> This works at the moment as it seems no-one really needs the requested
>>> capabilities.
>>> (I have to use a bundle instead of a feature because it should work in
>>> Karaf and inside any other OSGi runtime that does not know about Karaf
>>> specific stuff e.g. features).
>>>
>>> Wouldn't it be better to get / "know" the correct bundle set to get it
>>> working and perhaps create some PRs to get it working everywhere
>>> instead of fixing it downstream on my side only?
>>>
>>> I will provide the specific messages later.
>>> AFAIK servicemix already provides some API bundles (for other APIs)
>>> that differ between the plain API bundles as the servicemix ones
>>> contains a serviceloader and that manifest entries.
>>>
>>> Best regards,
>>> Markus
>>>
>>> Am So., 15. Sept. 2019 um 19:19 Uhr schrieb Jean-Baptiste Onofré
>>> <[hidden email]>:
>>>>
>>>> First, you can also embed Johnzon as private package in your bundle,
>>>> that's probably the easiest way.
>>>>
>>>> All is not necessary bundle and import in OSGi ! I don't understand why
>>>> the users systematically wants bundles/imports for everything ;)
>>>>
>>>> Anyway, can you share exactly the message ? The missing is not a bundle,
>>>> it's a capability (service.loader). It's something you can add in a
>>>> feature for instance.
>>>>
>>>> What I propose to you is to create a features for that.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 15/09/2019 12:20, Markus Rathgeb wrote:
>>>>> Hi,
>>>>>
>>>>> I posted my problem already to the Johnzon mailing list and have been
>>>>> told to ask the Karaf team. So please let me ask you (this should be
>>>>> no cross posting).
>>>>> See: https://lists.apache.org/thread.html/b2134d2002738d33a57a329966ef38563372613502947158358092fa@%3Cdev.johnzon.apache.org%3E
>>>>>
>>>>> I am not really sure if Karaf is using Johnzon. The current master
>>>>> source tree only finds the usage of johnzon-core and johnzon-mapper on
>>>>> an camel demo / example and it uses a rather old version (0.95).
>>>>> But as you "know" a lot of OSGi bundles you perhaps know which one
>>>>> satisfy the respective requirements.
>>>>>
>>>>> Let me repeat the description of my problem:
>>>>>
>>>>> I would like to use johnzon-jsonb 1.1.12 in an OSGi container.
>>>>>
>>>>> After adding johnzon-jsonb I got:
>>>>> osgi.wiring.package: (&(osgi.wiring.package=javax.json.bind))
>>>>>
>>>>> That's easy, we need the respective API bundle.
>>>>> I added org.apache.geronimo.specs/geronimo-jsonb_1.0_spec/1.1
>>>>>
>>>>> johnzon-jsonb requires: osgi.contract: (&(osgi.contract=JavaCDI)(version=2.0.0))
>>>>> I added org.apache.geronimo.specs/geronimo-jcdi_2.0_spec/1.1
>>>>> This bundle provides the JavaCDI contract version 2.0.0
>>>>>
>>>>> The jcdi bundle requires: osgi.wiring.package: (&(osgi.wiring.package=javax.el))
>>>>> I added org.apache.geronimo.specs/geronimo-el_2.2_spec/1.1
>>>>>
>>>>> The jcdi also requires: osgi.wiring.package:
>>>>> (&(osgi.wiring.package=javax.inject))
>>>>> I added org.apache.geronimo.specs/geronimo-atinject_1.0_spec/1.1
>>>>>
>>>>> The jcdi also requires: osgi.serviceloader:
>>>>> (osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)
>>>>>
>>>>> I don't know which bundle provides that service loader.
>>>>>
>>>>> Can you please point me to a set of bundles to use Johnzon JSON-B in OSGi?
>>>>>
>>>>> With regards,
>>>>> Markus
>>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> [hidden email]
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>
>> --
>> Jean-Baptiste Onofré
>> [hidden email]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Johnzon JSON-B on OSGi

maggu2810
Hi again,
be back with all the information (hopefully)

For JSON-P provided by Johnzon:
===

bundle:install mvn:org.apache.aries.spifly/org.apache.aries.spifly.dynamic.bundle/1.2.3
bundle:install mvn:org.apache.geronimo.specs/geronimo-json_1.1_spec/1.2
bundle:install -s mvn:org.apache.johnzon/johnzon-core/1.1.12

So far, all fine.




Next try for JSON-B provided by Johnzon
===

The manifest of johnzon-jsonb contains (excerpt):

...
Require-Capability =
        osgi.extender;filter:=(osgi.extender=osgi.serviceloader.registrar),
        osgi.contract;filter:=(&(osgi.contract=JavaCDI)(version=2.0.0));osgi.contract=JavaCDI,
        osgi.contract;filter:=(&(osgi.contract=JavaJSONP)(version=1.1.0));osgi.contract=JavaJSONP,
        osgi.contract;filter:=(&(osgi.contract=JavaAnnotation)(version=1.3.0));osgi.contract=JavaAnnotation,
        osgi.contract;filter:=(&(osgi.contract=JavaJAXRS)(version=2.1.0));osgi.contract=JavaJAXRS,
        osgi.contract;filter:=(&(osgi.contract=JavaJSONB)(version=1.0.0));osgi.contract=JavaJSONB,
        osgi.ee;filter:=(&(osgi.ee=JavaSE)(version=1.8))
...
Import-Package =
        javax.annotation,
        javax.enterprise.context.spi;resolution:=optional,
        javax.enterprise.event;resolution:=optional,
        javax.enterprise.inject.spi;resolution:=optional,
        javax.json,
        javax.json.bind,
        javax.json.bind.adapter,
        javax.json.bind.annotation,
        javax.json.bind.config,
        javax.json.bind.serializer,
        javax.json.bind.spi,
        javax.json.spi,
        javax.json.stream,
        javax.ws.rs,
        javax.ws.rs.core,
        javax.ws.rs.ext,
        org.apache.johnzon.core;version="[1.1,2)",
        org.apache.johnzon.jsonb,
        org.apache.johnzon.jsonb.cdi,
        org.apache.johnzon.jsonb.converter,
        org.apache.johnzon.jsonb.extension,
        org.apache.johnzon.jsonb.factory,
        org.apache.johnzon.jsonb.serializer,
        org.apache.johnzon.jsonb.spi,
        org.apache.johnzon.mapper;version="[1.1,2)",
        org.apache.johnzon.mapper.access;version="[1.1,2)",
        org.apache.johnzon.mapper.converter;version="[1.1,2)",
        org.apache.johnzon.mapper.internal;version="[1.1,2)",
        org.apache.johnzon.mapper.reflection;version="[1.1,2)"


The first thing I wonder:
If the package imports are already marked as optional, makes it sense
to use a mandatory requirement for the OSGi contract?


Let's continue:

bundle:install mvn:org.apache.aries.spec/org.apache.aries.javax.jax.rs-api/1.0.0
bundle:install mvn:org.apache.geronimo.specs/geronimo-jsonb_1.0_spec/1.1
bundle:install mvn:org.apache.johnzon/johnzon-mapper/1.1.12
bundle:install mvn:org.apache.johnzon/johnzon-jsonb/1.1.12


Start Johnzon's JSON-B implementation
===
bundle:start "Johnzon :: JSON-B Implementation"
Error executing command: Error executing command on bundles:
        Error starting bundle 51: Unable to resolve
org.apache.johnzon.jsonb [51](R 51.0): missing requirement
[org.apache.johnzon.jsonb [51](R 51.0)] osgi.contract;
(&(osgi.contract=JavaCDI)(version=2.0.0)) Unresolved requirements:
[[org.apache.johnzon.jsonb [51](R 51.0)] osgi.contract;
(&(osgi.contract=JavaCDI)(version=2.0.0))]
===


So, let's find a bundle that provides the JavaCDI v2.0.0 contract.
===
karaf@root()> bundle:install
mvn:org.apache.geronimo.specs/geronimo-jcdi_2.0_spec/1.1
karaf@root()> bundle:start "Apache Geronimo JCDI Spec 2.0"
Error executing command: Error executing command on bundles:
        Error starting bundle 52: Unable to resolve
org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0): missing
requirement [org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R
52.0)] osgi.wiring.package; (osgi.wiring.package=javax.el) Unresolved
requirements: [[org.apache.geronimo.specs.geronimo-jcdi_2.0_spec
[52](R 52.0)] osgi.wiring.package; (osgi.wiring.package=javax.el)]
===

Let's find a bundle that exports javax.el.
===
bundle:install mvn:org.apache.geronimo.specs/geronimo-el_2.2_spec/1.1
bundle:start "Apache Geronimo Expression Language Spec 2.2"
===
Done

Try to start JCDI again.
===
karaf@root()> bundle:start "Apache Geronimo JCDI Spec 2.0"
Error executing command: Error executing command on bundles:
        Error starting bundle 52: Unable to resolve
org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0): missing
requirement [org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R
52.0)] osgi.wiring.package; (osgi.wiring.package=javax.inject)
Unresolved requirements:
[[org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0)]
osgi.wiring.package; (osgi.wiring.package=javax.inject)]
===

Let's find a bundle that exports javax.inject
===
karaf@root()> bundle:install
mvn:org.apache.geronimo.specs/geronimo-atinject_1.0_spec/1.1
karaf@root()> bundle:start "Apache Geronimo JSR-330 Spec 1.0"
===
Done

Try to start JCDI again.
===
karaf@root()> bundle:start "Apache Geronimo JCDI Spec 2.0"
Error executing command: Error executing command on bundles:
        Error starting bundle 52: Unable to resolve
org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0): missing
requirement [org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R
52.0)] osgi.wiring.package; (osgi.wiring.package=javax.interceptor)
Unresolved requirements:
[[org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0)]
osgi.wiring.package; (osgi.wiring.package=javax.interceptor)]
===

Let's find a bundle that exports javax.interceptor
===
karaf@root()> bundle:install
mvn:org.apache.geronimo.specs/geronimo-interceptor_1.2_spec/1.1
karaf@root()> bundle:start "Apache Geronimo Interceptor Spec 1.2"
===

Try to start JCDI again.
===
karaf@root()> bundle:start "Apache Geronimo JCDI Spec 2.0"
Error executing command: Error executing command on bundles:
        Error starting bundle 52: Unable to resolve
org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0): missing
requirement [org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R
52.0)] osgi.serviceloader;
(osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)
Unresolved requirements:
[[org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0)]
osgi.serviceloader;
(osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)]
===


So, I need "something" that provides a ServiceLoader for
"javax.enterprise.inject.se.SeContainerInitializer" or another  bundle
that provides the JavaCDI v2.0.0 contract.



If CDI is optional for Johnzon JSON-B as the option imports of
"javax.enterprise.*" suggests, perhaps the contract should be removed
or marked optional (can a contract be marked optional at all?).

But regardless of Johnzon at all, how can "Apache Geronimo JCDI Spec
2.0" be satisfied at all?

Best regards,
Markus

Am Mo., 16. Sept. 2019 um 07:54 Uhr schrieb Jean-Baptiste Onofré
<[hidden email]>:

>
> That's exactly my point: johnzon-jsonb should not expose johnzon
> packages at all.
>
> Back on cap, for service loader, the SPI bundle should provide it:
>
> https://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
>
> So, if johnzon-jsonb doesn't provide, it's a mistake in this bundle IMHO.
>
> Regards
> JB
>
> On 16/09/2019 07:43, Markus Rathgeb wrote:
> > Hi,
> >
> >> However, the JSON-B impl using Johnzon
> >> can embed Johnzon as private and just expose JSON-B service.
> >> That's actually better IMHO as you hide the implementation details from
> >> the API.
> >> That's the purpose of OSGi IMHO.
> >
> > From my understanding this is exactly what johnzon-jsonb should provide:
> > "Johnzon provides a module johnzon-jsonb implementing JSON-B standard
> > based on Johnzon Mapper."
> >
> > johnzon-josnb uses internally the johnzon-mapper implementation to
> > provide that functionality by the JSON-B API.
> >
> > I just want to use the JSON-B API in all my implementations and use
> > johnzon-jsonb as a bundle that provides a JSON-B implementation (the
> > fact that Johnzon [Mapper] is used I don't really care about).
> > johnzon-jsonb an OSGi manifest so I would like to get it running ;)
> >
> >> The question is why "client" bundles have a requirement not already
> >> provided or existing.
> >
> > Good question, I don't know.
> > My assumption has been, that the bundle exists that provides the
> > required capabilities, I just don't find them.
> > So my request: Does anyone know about the bundle(s) that provide the
> > capabilities.
> >
> > I will post the required capas soon (if I am back on my working machine).
> >
> > Best regards,
> > Markus
> >
> >>
> >> We already did some "wrapped" bundles (for instance Aries JAXRS API) in
> >> such case.
> >> More than a bundle, it's maybe better to evaluate to provide such
> >> capability at feature level.
> >>
> >> Regards
> >> JB
> >>
> >> On 16/09/2019 07:00, Markus Rathgeb wrote:
> >>> Hi JB,
> >>>
> >>> thanks for your reply.
> >>>
> >>> About your comment that you don't understand why people would like to
> >>> use OSGi bundles if possible instead of import stuff into private
> >>> packages:
> >>>
> >>> Isn't one thing we prefer in OSGi that we program / compile against an
> >>> API instead of a specific implementation?
> >>> I would like to move from Jackson, Gson, Johnzon Mapper usage (hard
> >>> dependency because using that specific implementation) to JSON-P
> >>> (JSR-353) and JSON-B (JSR-367).
> >>> Doesn't it make sense (for you) to such an official standard?
> >>>
> >>> After more and more bundles (of mine) will be migrated to e.g. JSON-B
> >>> I would like to use JSON-B in my OSGi environments easily.
> >>> Just state that there must be such an implementation available at runtime.
> >>>
> >>> Is this wrong?
> >>> Isn't that exactly what has been chosen for the reference
> >>> implementation of the Configurator by Apache Felix?
> >>> They didn't embed an JSON-P implementation in the configurator bundle
> >>> but an implementation of our choose can be used at runtime.
> >>>
> >>> johnzon-jsonb already contains the OSGi related headers in its
> >>> manifest I just want to get it working.
> >>> I already created a fake bundle that just tell the runtime it would
> >>> provide the requested capability (without providing it).
> >>> This works at the moment as it seems no-one really needs the requested
> >>> capabilities.
> >>> (I have to use a bundle instead of a feature because it should work in
> >>> Karaf and inside any other OSGi runtime that does not know about Karaf
> >>> specific stuff e.g. features).
> >>>
> >>> Wouldn't it be better to get / "know" the correct bundle set to get it
> >>> working and perhaps create some PRs to get it working everywhere
> >>> instead of fixing it downstream on my side only?
> >>>
> >>> I will provide the specific messages later.
> >>> AFAIK servicemix already provides some API bundles (for other APIs)
> >>> that differ between the plain API bundles as the servicemix ones
> >>> contains a serviceloader and that manifest entries.
> >>>
> >>> Best regards,
> >>> Markus
> >>>
> >>> Am So., 15. Sept. 2019 um 19:19 Uhr schrieb Jean-Baptiste Onofré
> >>> <[hidden email]>:
> >>>>
> >>>> First, you can also embed Johnzon as private package in your bundle,
> >>>> that's probably the easiest way.
> >>>>
> >>>> All is not necessary bundle and import in OSGi ! I don't understand why
> >>>> the users systematically wants bundles/imports for everything ;)
> >>>>
> >>>> Anyway, can you share exactly the message ? The missing is not a bundle,
> >>>> it's a capability (service.loader). It's something you can add in a
> >>>> feature for instance.
> >>>>
> >>>> What I propose to you is to create a features for that.
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On 15/09/2019 12:20, Markus Rathgeb wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I posted my problem already to the Johnzon mailing list and have been
> >>>>> told to ask the Karaf team. So please let me ask you (this should be
> >>>>> no cross posting).
> >>>>> See: https://lists.apache.org/thread.html/b2134d2002738d33a57a329966ef38563372613502947158358092fa@%3Cdev.johnzon.apache.org%3E
> >>>>>
> >>>>> I am not really sure if Karaf is using Johnzon. The current master
> >>>>> source tree only finds the usage of johnzon-core and johnzon-mapper on
> >>>>> an camel demo / example and it uses a rather old version (0.95).
> >>>>> But as you "know" a lot of OSGi bundles you perhaps know which one
> >>>>> satisfy the respective requirements.
> >>>>>
> >>>>> Let me repeat the description of my problem:
> >>>>>
> >>>>> I would like to use johnzon-jsonb 1.1.12 in an OSGi container.
> >>>>>
> >>>>> After adding johnzon-jsonb I got:
> >>>>> osgi.wiring.package: (&(osgi.wiring.package=javax.json.bind))
> >>>>>
> >>>>> That's easy, we need the respective API bundle.
> >>>>> I added org.apache.geronimo.specs/geronimo-jsonb_1.0_spec/1.1
> >>>>>
> >>>>> johnzon-jsonb requires: osgi.contract: (&(osgi.contract=JavaCDI)(version=2.0.0))
> >>>>> I added org.apache.geronimo.specs/geronimo-jcdi_2.0_spec/1.1
> >>>>> This bundle provides the JavaCDI contract version 2.0.0
> >>>>>
> >>>>> The jcdi bundle requires: osgi.wiring.package: (&(osgi.wiring.package=javax.el))
> >>>>> I added org.apache.geronimo.specs/geronimo-el_2.2_spec/1.1
> >>>>>
> >>>>> The jcdi also requires: osgi.wiring.package:
> >>>>> (&(osgi.wiring.package=javax.inject))
> >>>>> I added org.apache.geronimo.specs/geronimo-atinject_1.0_spec/1.1
> >>>>>
> >>>>> The jcdi also requires: osgi.serviceloader:
> >>>>> (osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)
> >>>>>
> >>>>> I don't know which bundle provides that service loader.
> >>>>>
> >>>>> Can you please point me to a set of bundles to use Johnzon JSON-B in OSGi?
> >>>>>
> >>>>> With regards,
> >>>>> Markus
> >>>>>
> >>>>
> >>>> --
> >>>> Jean-Baptiste Onofré
> >>>> [hidden email]
> >>>> http://blog.nanthrax.net
> >>>> Talend - http://www.talend.com
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> [hidden email]
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Johnzon JSON-B on OSGi

maggu2810
Hi,

as I did not found a set of bundle that satisfy the contract JavaCDI
v2.0.0 I repackaged the Johnzon JSON-B bundle to not depend on CDI at
all.

A question about the serviceloader specific manifest entries (WRT to
the example from
https://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html):

The bundle that provides an implementation by SPI should contain that
manifest headers:

Require-Capability:
osgi.extender;filter:="(osgi.extender=osgi.serviceloader.registrar)"
Provide-Capability: osgi.serviceloader;osgi.serviceloader=foo.bar.MySPI

Let's name it bundle_provider for the moment.

If my reading has been correct the ServiceLoader Registrar (e.g.
SPI-fly) register the specific implementation class OSGi Services so
that OSGi-aware consumers can simply use them from the OSGi Service
Registry.

If "@Reference foo.bar.MySPI" is used in a component (so a consumer)
the bnd tooling will generate that manifest header:

Require-Capability:
osgi.service;filter:="(objectClass=foo.bar.MySPI)";effective:=active

Wouldn't it make sense if bundle_provider also contains the header:

Provide-Capability: osgi.service;objectClass:List<String>="foo.bar.MySPI"

As bundle_provider requires the ServiceLoader Registrar can't it state
that the OSGi is provided?

Or should the requirement
osgi.service;filter:="(objectClass=foo.bar.MySPI)";effective:=active
also be satisfied by the provided
osgi.serviceloader;osgi.serviceloader=foo.bar.MySPI (and its
requirement for the Registrar)
by resolving utils?

Best regards,
Markus

Am Mo., 16. Sept. 2019 um 11:14 Uhr schrieb Markus Rathgeb
<[hidden email]>:

>
> Hi again,
> be back with all the information (hopefully)
>
> For JSON-P provided by Johnzon:
> ===
>
> bundle:install mvn:org.apache.aries.spifly/org.apache.aries.spifly.dynamic.bundle/1.2.3
> bundle:install mvn:org.apache.geronimo.specs/geronimo-json_1.1_spec/1.2
> bundle:install -s mvn:org.apache.johnzon/johnzon-core/1.1.12
>
> So far, all fine.
>
>
>
>
> Next try for JSON-B provided by Johnzon
> ===
>
> The manifest of johnzon-jsonb contains (excerpt):
>
> ...
> Require-Capability =
>         osgi.extender;filter:=(osgi.extender=osgi.serviceloader.registrar),
>         osgi.contract;filter:=(&(osgi.contract=JavaCDI)(version=2.0.0));osgi.contract=JavaCDI,
>         osgi.contract;filter:=(&(osgi.contract=JavaJSONP)(version=1.1.0));osgi.contract=JavaJSONP,
>         osgi.contract;filter:=(&(osgi.contract=JavaAnnotation)(version=1.3.0));osgi.contract=JavaAnnotation,
>         osgi.contract;filter:=(&(osgi.contract=JavaJAXRS)(version=2.1.0));osgi.contract=JavaJAXRS,
>         osgi.contract;filter:=(&(osgi.contract=JavaJSONB)(version=1.0.0));osgi.contract=JavaJSONB,
>         osgi.ee;filter:=(&(osgi.ee=JavaSE)(version=1.8))
> ...
> Import-Package =
>         javax.annotation,
>         javax.enterprise.context.spi;resolution:=optional,
>         javax.enterprise.event;resolution:=optional,
>         javax.enterprise.inject.spi;resolution:=optional,
>         javax.json,
>         javax.json.bind,
>         javax.json.bind.adapter,
>         javax.json.bind.annotation,
>         javax.json.bind.config,
>         javax.json.bind.serializer,
>         javax.json.bind.spi,
>         javax.json.spi,
>         javax.json.stream,
>         javax.ws.rs,
>         javax.ws.rs.core,
>         javax.ws.rs.ext,
>         org.apache.johnzon.core;version="[1.1,2)",
>         org.apache.johnzon.jsonb,
>         org.apache.johnzon.jsonb.cdi,
>         org.apache.johnzon.jsonb.converter,
>         org.apache.johnzon.jsonb.extension,
>         org.apache.johnzon.jsonb.factory,
>         org.apache.johnzon.jsonb.serializer,
>         org.apache.johnzon.jsonb.spi,
>         org.apache.johnzon.mapper;version="[1.1,2)",
>         org.apache.johnzon.mapper.access;version="[1.1,2)",
>         org.apache.johnzon.mapper.converter;version="[1.1,2)",
>         org.apache.johnzon.mapper.internal;version="[1.1,2)",
>         org.apache.johnzon.mapper.reflection;version="[1.1,2)"
>
>
> The first thing I wonder:
> If the package imports are already marked as optional, makes it sense
> to use a mandatory requirement for the OSGi contract?
>
>
> Let's continue:
>
> bundle:install mvn:org.apache.aries.spec/org.apache.aries.javax.jax.rs-api/1.0.0
> bundle:install mvn:org.apache.geronimo.specs/geronimo-jsonb_1.0_spec/1.1
> bundle:install mvn:org.apache.johnzon/johnzon-mapper/1.1.12
> bundle:install mvn:org.apache.johnzon/johnzon-jsonb/1.1.12
>
>
> Start Johnzon's JSON-B implementation
> ===
> bundle:start "Johnzon :: JSON-B Implementation"
> Error executing command: Error executing command on bundles:
>         Error starting bundle 51: Unable to resolve
> org.apache.johnzon.jsonb [51](R 51.0): missing requirement
> [org.apache.johnzon.jsonb [51](R 51.0)] osgi.contract;
> (&(osgi.contract=JavaCDI)(version=2.0.0)) Unresolved requirements:
> [[org.apache.johnzon.jsonb [51](R 51.0)] osgi.contract;
> (&(osgi.contract=JavaCDI)(version=2.0.0))]
> ===
>
>
> So, let's find a bundle that provides the JavaCDI v2.0.0 contract.
> ===
> karaf@root()> bundle:install
> mvn:org.apache.geronimo.specs/geronimo-jcdi_2.0_spec/1.1
> karaf@root()> bundle:start "Apache Geronimo JCDI Spec 2.0"
> Error executing command: Error executing command on bundles:
>         Error starting bundle 52: Unable to resolve
> org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0): missing
> requirement [org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R
> 52.0)] osgi.wiring.package; (osgi.wiring.package=javax.el) Unresolved
> requirements: [[org.apache.geronimo.specs.geronimo-jcdi_2.0_spec
> [52](R 52.0)] osgi.wiring.package; (osgi.wiring.package=javax.el)]
> ===
>
> Let's find a bundle that exports javax.el.
> ===
> bundle:install mvn:org.apache.geronimo.specs/geronimo-el_2.2_spec/1.1
> bundle:start "Apache Geronimo Expression Language Spec 2.2"
> ===
> Done
>
> Try to start JCDI again.
> ===
> karaf@root()> bundle:start "Apache Geronimo JCDI Spec 2.0"
> Error executing command: Error executing command on bundles:
>         Error starting bundle 52: Unable to resolve
> org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0): missing
> requirement [org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R
> 52.0)] osgi.wiring.package; (osgi.wiring.package=javax.inject)
> Unresolved requirements:
> [[org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0)]
> osgi.wiring.package; (osgi.wiring.package=javax.inject)]
> ===
>
> Let's find a bundle that exports javax.inject
> ===
> karaf@root()> bundle:install
> mvn:org.apache.geronimo.specs/geronimo-atinject_1.0_spec/1.1
> karaf@root()> bundle:start "Apache Geronimo JSR-330 Spec 1.0"
> ===
> Done
>
> Try to start JCDI again.
> ===
> karaf@root()> bundle:start "Apache Geronimo JCDI Spec 2.0"
> Error executing command: Error executing command on bundles:
>         Error starting bundle 52: Unable to resolve
> org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0): missing
> requirement [org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R
> 52.0)] osgi.wiring.package; (osgi.wiring.package=javax.interceptor)
> Unresolved requirements:
> [[org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0)]
> osgi.wiring.package; (osgi.wiring.package=javax.interceptor)]
> ===
>
> Let's find a bundle that exports javax.interceptor
> ===
> karaf@root()> bundle:install
> mvn:org.apache.geronimo.specs/geronimo-interceptor_1.2_spec/1.1
> karaf@root()> bundle:start "Apache Geronimo Interceptor Spec 1.2"
> ===
>
> Try to start JCDI again.
> ===
> karaf@root()> bundle:start "Apache Geronimo JCDI Spec 2.0"
> Error executing command: Error executing command on bundles:
>         Error starting bundle 52: Unable to resolve
> org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0): missing
> requirement [org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R
> 52.0)] osgi.serviceloader;
> (osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)
> Unresolved requirements:
> [[org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0)]
> osgi.serviceloader;
> (osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)]
> ===
>
>
> So, I need "something" that provides a ServiceLoader for
> "javax.enterprise.inject.se.SeContainerInitializer" or another  bundle
> that provides the JavaCDI v2.0.0 contract.
>
>
>
> If CDI is optional for Johnzon JSON-B as the option imports of
> "javax.enterprise.*" suggests, perhaps the contract should be removed
> or marked optional (can a contract be marked optional at all?).
>
> But regardless of Johnzon at all, how can "Apache Geronimo JCDI Spec
> 2.0" be satisfied at all?
>
> Best regards,
> Markus
>
> Am Mo., 16. Sept. 2019 um 07:54 Uhr schrieb Jean-Baptiste Onofré
> <[hidden email]>:
> >
> > That's exactly my point: johnzon-jsonb should not expose johnzon
> > packages at all.
> >
> > Back on cap, for service loader, the SPI bundle should provide it:
> >
> > https://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
> >
> > So, if johnzon-jsonb doesn't provide, it's a mistake in this bundle IMHO.
> >
> > Regards
> > JB
> >
> > On 16/09/2019 07:43, Markus Rathgeb wrote:
> > > Hi,
> > >
> > >> However, the JSON-B impl using Johnzon
> > >> can embed Johnzon as private and just expose JSON-B service.
> > >> That's actually better IMHO as you hide the implementation details from
> > >> the API.
> > >> That's the purpose of OSGi IMHO.
> > >
> > > From my understanding this is exactly what johnzon-jsonb should provide:
> > > "Johnzon provides a module johnzon-jsonb implementing JSON-B standard
> > > based on Johnzon Mapper."
> > >
> > > johnzon-josnb uses internally the johnzon-mapper implementation to
> > > provide that functionality by the JSON-B API.
> > >
> > > I just want to use the JSON-B API in all my implementations and use
> > > johnzon-jsonb as a bundle that provides a JSON-B implementation (the
> > > fact that Johnzon [Mapper] is used I don't really care about).
> > > johnzon-jsonb an OSGi manifest so I would like to get it running ;)
> > >
> > >> The question is why "client" bundles have a requirement not already
> > >> provided or existing.
> > >
> > > Good question, I don't know.
> > > My assumption has been, that the bundle exists that provides the
> > > required capabilities, I just don't find them.
> > > So my request: Does anyone know about the bundle(s) that provide the
> > > capabilities.
> > >
> > > I will post the required capas soon (if I am back on my working machine).
> > >
> > > Best regards,
> > > Markus
> > >
> > >>
> > >> We already did some "wrapped" bundles (for instance Aries JAXRS API) in
> > >> such case.
> > >> More than a bundle, it's maybe better to evaluate to provide such
> > >> capability at feature level.
> > >>
> > >> Regards
> > >> JB
> > >>
> > >> On 16/09/2019 07:00, Markus Rathgeb wrote:
> > >>> Hi JB,
> > >>>
> > >>> thanks for your reply.
> > >>>
> > >>> About your comment that you don't understand why people would like to
> > >>> use OSGi bundles if possible instead of import stuff into private
> > >>> packages:
> > >>>
> > >>> Isn't one thing we prefer in OSGi that we program / compile against an
> > >>> API instead of a specific implementation?
> > >>> I would like to move from Jackson, Gson, Johnzon Mapper usage (hard
> > >>> dependency because using that specific implementation) to JSON-P
> > >>> (JSR-353) and JSON-B (JSR-367).
> > >>> Doesn't it make sense (for you) to such an official standard?
> > >>>
> > >>> After more and more bundles (of mine) will be migrated to e.g. JSON-B
> > >>> I would like to use JSON-B in my OSGi environments easily.
> > >>> Just state that there must be such an implementation available at runtime.
> > >>>
> > >>> Is this wrong?
> > >>> Isn't that exactly what has been chosen for the reference
> > >>> implementation of the Configurator by Apache Felix?
> > >>> They didn't embed an JSON-P implementation in the configurator bundle
> > >>> but an implementation of our choose can be used at runtime.
> > >>>
> > >>> johnzon-jsonb already contains the OSGi related headers in its
> > >>> manifest I just want to get it working.
> > >>> I already created a fake bundle that just tell the runtime it would
> > >>> provide the requested capability (without providing it).
> > >>> This works at the moment as it seems no-one really needs the requested
> > >>> capabilities.
> > >>> (I have to use a bundle instead of a feature because it should work in
> > >>> Karaf and inside any other OSGi runtime that does not know about Karaf
> > >>> specific stuff e.g. features).
> > >>>
> > >>> Wouldn't it be better to get / "know" the correct bundle set to get it
> > >>> working and perhaps create some PRs to get it working everywhere
> > >>> instead of fixing it downstream on my side only?
> > >>>
> > >>> I will provide the specific messages later.
> > >>> AFAIK servicemix already provides some API bundles (for other APIs)
> > >>> that differ between the plain API bundles as the servicemix ones
> > >>> contains a serviceloader and that manifest entries.
> > >>>
> > >>> Best regards,
> > >>> Markus
> > >>>
> > >>> Am So., 15. Sept. 2019 um 19:19 Uhr schrieb Jean-Baptiste Onofré
> > >>> <[hidden email]>:
> > >>>>
> > >>>> First, you can also embed Johnzon as private package in your bundle,
> > >>>> that's probably the easiest way.
> > >>>>
> > >>>> All is not necessary bundle and import in OSGi ! I don't understand why
> > >>>> the users systematically wants bundles/imports for everything ;)
> > >>>>
> > >>>> Anyway, can you share exactly the message ? The missing is not a bundle,
> > >>>> it's a capability (service.loader). It's something you can add in a
> > >>>> feature for instance.
> > >>>>
> > >>>> What I propose to you is to create a features for that.
> > >>>>
> > >>>> Regards
> > >>>> JB
> > >>>>
> > >>>> On 15/09/2019 12:20, Markus Rathgeb wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>> I posted my problem already to the Johnzon mailing list and have been
> > >>>>> told to ask the Karaf team. So please let me ask you (this should be
> > >>>>> no cross posting).
> > >>>>> See: https://lists.apache.org/thread.html/b2134d2002738d33a57a329966ef38563372613502947158358092fa@%3Cdev.johnzon.apache.org%3E
> > >>>>>
> > >>>>> I am not really sure if Karaf is using Johnzon. The current master
> > >>>>> source tree only finds the usage of johnzon-core and johnzon-mapper on
> > >>>>> an camel demo / example and it uses a rather old version (0.95).
> > >>>>> But as you "know" a lot of OSGi bundles you perhaps know which one
> > >>>>> satisfy the respective requirements.
> > >>>>>
> > >>>>> Let me repeat the description of my problem:
> > >>>>>
> > >>>>> I would like to use johnzon-jsonb 1.1.12 in an OSGi container.
> > >>>>>
> > >>>>> After adding johnzon-jsonb I got:
> > >>>>> osgi.wiring.package: (&(osgi.wiring.package=javax.json.bind))
> > >>>>>
> > >>>>> That's easy, we need the respective API bundle.
> > >>>>> I added org.apache.geronimo.specs/geronimo-jsonb_1.0_spec/1.1
> > >>>>>
> > >>>>> johnzon-jsonb requires: osgi.contract: (&(osgi.contract=JavaCDI)(version=2.0.0))
> > >>>>> I added org.apache.geronimo.specs/geronimo-jcdi_2.0_spec/1.1
> > >>>>> This bundle provides the JavaCDI contract version 2.0.0
> > >>>>>
> > >>>>> The jcdi bundle requires: osgi.wiring.package: (&(osgi.wiring.package=javax.el))
> > >>>>> I added org.apache.geronimo.specs/geronimo-el_2.2_spec/1.1
> > >>>>>
> > >>>>> The jcdi also requires: osgi.wiring.package:
> > >>>>> (&(osgi.wiring.package=javax.inject))
> > >>>>> I added org.apache.geronimo.specs/geronimo-atinject_1.0_spec/1.1
> > >>>>>
> > >>>>> The jcdi also requires: osgi.serviceloader:
> > >>>>> (osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)
> > >>>>>
> > >>>>> I don't know which bundle provides that service loader.
> > >>>>>
> > >>>>> Can you please point me to a set of bundles to use Johnzon JSON-B in OSGi?
> > >>>>>
> > >>>>> With regards,
> > >>>>> Markus
> > >>>>>
> > >>>>
> > >>>> --
> > >>>> Jean-Baptiste Onofré
> > >>>> [hidden email]
> > >>>> http://blog.nanthrax.net
> > >>>> Talend - http://www.talend.com
> > >>
> > >> --
> > >> Jean-Baptiste Onofré
> > >> [hidden email]
> > >> http://blog.nanthrax.net
> > >> Talend - http://www.talend.com
> >
> > --
> > Jean-Baptiste Onofré
> > [hidden email]
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Johnzon JSON-B on OSGi

jbonofre
Hi Markus,

I'm busy finalizing Karaf 4.2.7 release preparation.

I will take a complete look and get back to you later today.

Regards
JB

On 19/09/2019 10:24, Markus Rathgeb wrote:

> Hi,
>
> as I did not found a set of bundle that satisfy the contract JavaCDI
> v2.0.0 I repackaged the Johnzon JSON-B bundle to not depend on CDI at
> all.
>
> A question about the serviceloader specific manifest entries (WRT to
> the example from
> https://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html):
>
> The bundle that provides an implementation by SPI should contain that
> manifest headers:
>
> Require-Capability:
> osgi.extender;filter:="(osgi.extender=osgi.serviceloader.registrar)"
> Provide-Capability: osgi.serviceloader;osgi.serviceloader=foo.bar.MySPI
>
> Let's name it bundle_provider for the moment.
>
> If my reading has been correct the ServiceLoader Registrar (e.g.
> SPI-fly) register the specific implementation class OSGi Services so
> that OSGi-aware consumers can simply use them from the OSGi Service
> Registry.
>
> If "@Reference foo.bar.MySPI" is used in a component (so a consumer)
> the bnd tooling will generate that manifest header:
>
> Require-Capability:
> osgi.service;filter:="(objectClass=foo.bar.MySPI)";effective:=active
>
> Wouldn't it make sense if bundle_provider also contains the header:
>
> Provide-Capability: osgi.service;objectClass:List<String>="foo.bar.MySPI"
>
> As bundle_provider requires the ServiceLoader Registrar can't it state
> that the OSGi is provided?
>
> Or should the requirement
> osgi.service;filter:="(objectClass=foo.bar.MySPI)";effective:=active
> also be satisfied by the provided
> osgi.serviceloader;osgi.serviceloader=foo.bar.MySPI (and its
> requirement for the Registrar)
> by resolving utils?
>
> Best regards,
> Markus
>
> Am Mo., 16. Sept. 2019 um 11:14 Uhr schrieb Markus Rathgeb
> <[hidden email]>:
>>
>> Hi again,
>> be back with all the information (hopefully)
>>
>> For JSON-P provided by Johnzon:
>> ===
>>
>> bundle:install mvn:org.apache.aries.spifly/org.apache.aries.spifly.dynamic.bundle/1.2.3
>> bundle:install mvn:org.apache.geronimo.specs/geronimo-json_1.1_spec/1.2
>> bundle:install -s mvn:org.apache.johnzon/johnzon-core/1.1.12
>>
>> So far, all fine.
>>
>>
>>
>>
>> Next try for JSON-B provided by Johnzon
>> ===
>>
>> The manifest of johnzon-jsonb contains (excerpt):
>>
>> ...
>> Require-Capability =
>>         osgi.extender;filter:=(osgi.extender=osgi.serviceloader.registrar),
>>         osgi.contract;filter:=(&(osgi.contract=JavaCDI)(version=2.0.0));osgi.contract=JavaCDI,
>>         osgi.contract;filter:=(&(osgi.contract=JavaJSONP)(version=1.1.0));osgi.contract=JavaJSONP,
>>         osgi.contract;filter:=(&(osgi.contract=JavaAnnotation)(version=1.3.0));osgi.contract=JavaAnnotation,
>>         osgi.contract;filter:=(&(osgi.contract=JavaJAXRS)(version=2.1.0));osgi.contract=JavaJAXRS,
>>         osgi.contract;filter:=(&(osgi.contract=JavaJSONB)(version=1.0.0));osgi.contract=JavaJSONB,
>>         osgi.ee;filter:=(&(osgi.ee=JavaSE)(version=1.8))
>> ...
>> Import-Package =
>>         javax.annotation,
>>         javax.enterprise.context.spi;resolution:=optional,
>>         javax.enterprise.event;resolution:=optional,
>>         javax.enterprise.inject.spi;resolution:=optional,
>>         javax.json,
>>         javax.json.bind,
>>         javax.json.bind.adapter,
>>         javax.json.bind.annotation,
>>         javax.json.bind.config,
>>         javax.json.bind.serializer,
>>         javax.json.bind.spi,
>>         javax.json.spi,
>>         javax.json.stream,
>>         javax.ws.rs,
>>         javax.ws.rs.core,
>>         javax.ws.rs.ext,
>>         org.apache.johnzon.core;version="[1.1,2)",
>>         org.apache.johnzon.jsonb,
>>         org.apache.johnzon.jsonb.cdi,
>>         org.apache.johnzon.jsonb.converter,
>>         org.apache.johnzon.jsonb.extension,
>>         org.apache.johnzon.jsonb.factory,
>>         org.apache.johnzon.jsonb.serializer,
>>         org.apache.johnzon.jsonb.spi,
>>         org.apache.johnzon.mapper;version="[1.1,2)",
>>         org.apache.johnzon.mapper.access;version="[1.1,2)",
>>         org.apache.johnzon.mapper.converter;version="[1.1,2)",
>>         org.apache.johnzon.mapper.internal;version="[1.1,2)",
>>         org.apache.johnzon.mapper.reflection;version="[1.1,2)"
>>
>>
>> The first thing I wonder:
>> If the package imports are already marked as optional, makes it sense
>> to use a mandatory requirement for the OSGi contract?
>>
>>
>> Let's continue:
>>
>> bundle:install mvn:org.apache.aries.spec/org.apache.aries.javax.jax.rs-api/1.0.0
>> bundle:install mvn:org.apache.geronimo.specs/geronimo-jsonb_1.0_spec/1.1
>> bundle:install mvn:org.apache.johnzon/johnzon-mapper/1.1.12
>> bundle:install mvn:org.apache.johnzon/johnzon-jsonb/1.1.12
>>
>>
>> Start Johnzon's JSON-B implementation
>> ===
>> bundle:start "Johnzon :: JSON-B Implementation"
>> Error executing command: Error executing command on bundles:
>>         Error starting bundle 51: Unable to resolve
>> org.apache.johnzon.jsonb [51](R 51.0): missing requirement
>> [org.apache.johnzon.jsonb [51](R 51.0)] osgi.contract;
>> (&(osgi.contract=JavaCDI)(version=2.0.0)) Unresolved requirements:
>> [[org.apache.johnzon.jsonb [51](R 51.0)] osgi.contract;
>> (&(osgi.contract=JavaCDI)(version=2.0.0))]
>> ===
>>
>>
>> So, let's find a bundle that provides the JavaCDI v2.0.0 contract.
>> ===
>> karaf@root()> bundle:install
>> mvn:org.apache.geronimo.specs/geronimo-jcdi_2.0_spec/1.1
>> karaf@root()> bundle:start "Apache Geronimo JCDI Spec 2.0"
>> Error executing command: Error executing command on bundles:
>>         Error starting bundle 52: Unable to resolve
>> org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0): missing
>> requirement [org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R
>> 52.0)] osgi.wiring.package; (osgi.wiring.package=javax.el) Unresolved
>> requirements: [[org.apache.geronimo.specs.geronimo-jcdi_2.0_spec
>> [52](R 52.0)] osgi.wiring.package; (osgi.wiring.package=javax.el)]
>> ===
>>
>> Let's find a bundle that exports javax.el.
>> ===
>> bundle:install mvn:org.apache.geronimo.specs/geronimo-el_2.2_spec/1.1
>> bundle:start "Apache Geronimo Expression Language Spec 2.2"
>> ===
>> Done
>>
>> Try to start JCDI again.
>> ===
>> karaf@root()> bundle:start "Apache Geronimo JCDI Spec 2.0"
>> Error executing command: Error executing command on bundles:
>>         Error starting bundle 52: Unable to resolve
>> org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0): missing
>> requirement [org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R
>> 52.0)] osgi.wiring.package; (osgi.wiring.package=javax.inject)
>> Unresolved requirements:
>> [[org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0)]
>> osgi.wiring.package; (osgi.wiring.package=javax.inject)]
>> ===
>>
>> Let's find a bundle that exports javax.inject
>> ===
>> karaf@root()> bundle:install
>> mvn:org.apache.geronimo.specs/geronimo-atinject_1.0_spec/1.1
>> karaf@root()> bundle:start "Apache Geronimo JSR-330 Spec 1.0"
>> ===
>> Done
>>
>> Try to start JCDI again.
>> ===
>> karaf@root()> bundle:start "Apache Geronimo JCDI Spec 2.0"
>> Error executing command: Error executing command on bundles:
>>         Error starting bundle 52: Unable to resolve
>> org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0): missing
>> requirement [org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R
>> 52.0)] osgi.wiring.package; (osgi.wiring.package=javax.interceptor)
>> Unresolved requirements:
>> [[org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0)]
>> osgi.wiring.package; (osgi.wiring.package=javax.interceptor)]
>> ===
>>
>> Let's find a bundle that exports javax.interceptor
>> ===
>> karaf@root()> bundle:install
>> mvn:org.apache.geronimo.specs/geronimo-interceptor_1.2_spec/1.1
>> karaf@root()> bundle:start "Apache Geronimo Interceptor Spec 1.2"
>> ===
>>
>> Try to start JCDI again.
>> ===
>> karaf@root()> bundle:start "Apache Geronimo JCDI Spec 2.0"
>> Error executing command: Error executing command on bundles:
>>         Error starting bundle 52: Unable to resolve
>> org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0): missing
>> requirement [org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R
>> 52.0)] osgi.serviceloader;
>> (osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)
>> Unresolved requirements:
>> [[org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0)]
>> osgi.serviceloader;
>> (osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)]
>> ===
>>
>>
>> So, I need "something" that provides a ServiceLoader for
>> "javax.enterprise.inject.se.SeContainerInitializer" or another  bundle
>> that provides the JavaCDI v2.0.0 contract.
>>
>>
>>
>> If CDI is optional for Johnzon JSON-B as the option imports of
>> "javax.enterprise.*" suggests, perhaps the contract should be removed
>> or marked optional (can a contract be marked optional at all?).
>>
>> But regardless of Johnzon at all, how can "Apache Geronimo JCDI Spec
>> 2.0" be satisfied at all?
>>
>> Best regards,
>> Markus
>>
>> Am Mo., 16. Sept. 2019 um 07:54 Uhr schrieb Jean-Baptiste Onofré
>> <[hidden email]>:
>>>
>>> That's exactly my point: johnzon-jsonb should not expose johnzon
>>> packages at all.
>>>
>>> Back on cap, for service loader, the SPI bundle should provide it:
>>>
>>> https://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
>>>
>>> So, if johnzon-jsonb doesn't provide, it's a mistake in this bundle IMHO.
>>>
>>> Regards
>>> JB
>>>
>>> On 16/09/2019 07:43, Markus Rathgeb wrote:
>>>> Hi,
>>>>
>>>>> However, the JSON-B impl using Johnzon
>>>>> can embed Johnzon as private and just expose JSON-B service.
>>>>> That's actually better IMHO as you hide the implementation details from
>>>>> the API.
>>>>> That's the purpose of OSGi IMHO.
>>>>
>>>> From my understanding this is exactly what johnzon-jsonb should provide:
>>>> "Johnzon provides a module johnzon-jsonb implementing JSON-B standard
>>>> based on Johnzon Mapper."
>>>>
>>>> johnzon-josnb uses internally the johnzon-mapper implementation to
>>>> provide that functionality by the JSON-B API.
>>>>
>>>> I just want to use the JSON-B API in all my implementations and use
>>>> johnzon-jsonb as a bundle that provides a JSON-B implementation (the
>>>> fact that Johnzon [Mapper] is used I don't really care about).
>>>> johnzon-jsonb an OSGi manifest so I would like to get it running ;)
>>>>
>>>>> The question is why "client" bundles have a requirement not already
>>>>> provided or existing.
>>>>
>>>> Good question, I don't know.
>>>> My assumption has been, that the bundle exists that provides the
>>>> required capabilities, I just don't find them.
>>>> So my request: Does anyone know about the bundle(s) that provide the
>>>> capabilities.
>>>>
>>>> I will post the required capas soon (if I am back on my working machine).
>>>>
>>>> Best regards,
>>>> Markus
>>>>
>>>>>
>>>>> We already did some "wrapped" bundles (for instance Aries JAXRS API) in
>>>>> such case.
>>>>> More than a bundle, it's maybe better to evaluate to provide such
>>>>> capability at feature level.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 16/09/2019 07:00, Markus Rathgeb wrote:
>>>>>> Hi JB,
>>>>>>
>>>>>> thanks for your reply.
>>>>>>
>>>>>> About your comment that you don't understand why people would like to
>>>>>> use OSGi bundles if possible instead of import stuff into private
>>>>>> packages:
>>>>>>
>>>>>> Isn't one thing we prefer in OSGi that we program / compile against an
>>>>>> API instead of a specific implementation?
>>>>>> I would like to move from Jackson, Gson, Johnzon Mapper usage (hard
>>>>>> dependency because using that specific implementation) to JSON-P
>>>>>> (JSR-353) and JSON-B (JSR-367).
>>>>>> Doesn't it make sense (for you) to such an official standard?
>>>>>>
>>>>>> After more and more bundles (of mine) will be migrated to e.g. JSON-B
>>>>>> I would like to use JSON-B in my OSGi environments easily.
>>>>>> Just state that there must be such an implementation available at runtime.
>>>>>>
>>>>>> Is this wrong?
>>>>>> Isn't that exactly what has been chosen for the reference
>>>>>> implementation of the Configurator by Apache Felix?
>>>>>> They didn't embed an JSON-P implementation in the configurator bundle
>>>>>> but an implementation of our choose can be used at runtime.
>>>>>>
>>>>>> johnzon-jsonb already contains the OSGi related headers in its
>>>>>> manifest I just want to get it working.
>>>>>> I already created a fake bundle that just tell the runtime it would
>>>>>> provide the requested capability (without providing it).
>>>>>> This works at the moment as it seems no-one really needs the requested
>>>>>> capabilities.
>>>>>> (I have to use a bundle instead of a feature because it should work in
>>>>>> Karaf and inside any other OSGi runtime that does not know about Karaf
>>>>>> specific stuff e.g. features).
>>>>>>
>>>>>> Wouldn't it be better to get / "know" the correct bundle set to get it
>>>>>> working and perhaps create some PRs to get it working everywhere
>>>>>> instead of fixing it downstream on my side only?
>>>>>>
>>>>>> I will provide the specific messages later.
>>>>>> AFAIK servicemix already provides some API bundles (for other APIs)
>>>>>> that differ between the plain API bundles as the servicemix ones
>>>>>> contains a serviceloader and that manifest entries.
>>>>>>
>>>>>> Best regards,
>>>>>> Markus
>>>>>>
>>>>>> Am So., 15. Sept. 2019 um 19:19 Uhr schrieb Jean-Baptiste Onofré
>>>>>> <[hidden email]>:
>>>>>>>
>>>>>>> First, you can also embed Johnzon as private package in your bundle,
>>>>>>> that's probably the easiest way.
>>>>>>>
>>>>>>> All is not necessary bundle and import in OSGi ! I don't understand why
>>>>>>> the users systematically wants bundles/imports for everything ;)
>>>>>>>
>>>>>>> Anyway, can you share exactly the message ? The missing is not a bundle,
>>>>>>> it's a capability (service.loader). It's something you can add in a
>>>>>>> feature for instance.
>>>>>>>
>>>>>>> What I propose to you is to create a features for that.
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> On 15/09/2019 12:20, Markus Rathgeb wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I posted my problem already to the Johnzon mailing list and have been
>>>>>>>> told to ask the Karaf team. So please let me ask you (this should be
>>>>>>>> no cross posting).
>>>>>>>> See: https://lists.apache.org/thread.html/b2134d2002738d33a57a329966ef38563372613502947158358092fa@%3Cdev.johnzon.apache.org%3E
>>>>>>>>
>>>>>>>> I am not really sure if Karaf is using Johnzon. The current master
>>>>>>>> source tree only finds the usage of johnzon-core and johnzon-mapper on
>>>>>>>> an camel demo / example and it uses a rather old version (0.95).
>>>>>>>> But as you "know" a lot of OSGi bundles you perhaps know which one
>>>>>>>> satisfy the respective requirements.
>>>>>>>>
>>>>>>>> Let me repeat the description of my problem:
>>>>>>>>
>>>>>>>> I would like to use johnzon-jsonb 1.1.12 in an OSGi container.
>>>>>>>>
>>>>>>>> After adding johnzon-jsonb I got:
>>>>>>>> osgi.wiring.package: (&(osgi.wiring.package=javax.json.bind))
>>>>>>>>
>>>>>>>> That's easy, we need the respective API bundle.
>>>>>>>> I added org.apache.geronimo.specs/geronimo-jsonb_1.0_spec/1.1
>>>>>>>>
>>>>>>>> johnzon-jsonb requires: osgi.contract: (&(osgi.contract=JavaCDI)(version=2.0.0))
>>>>>>>> I added org.apache.geronimo.specs/geronimo-jcdi_2.0_spec/1.1
>>>>>>>> This bundle provides the JavaCDI contract version 2.0.0
>>>>>>>>
>>>>>>>> The jcdi bundle requires: osgi.wiring.package: (&(osgi.wiring.package=javax.el))
>>>>>>>> I added org.apache.geronimo.specs/geronimo-el_2.2_spec/1.1
>>>>>>>>
>>>>>>>> The jcdi also requires: osgi.wiring.package:
>>>>>>>> (&(osgi.wiring.package=javax.inject))
>>>>>>>> I added org.apache.geronimo.specs/geronimo-atinject_1.0_spec/1.1
>>>>>>>>
>>>>>>>> The jcdi also requires: osgi.serviceloader:
>>>>>>>> (osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)
>>>>>>>>
>>>>>>>> I don't know which bundle provides that service loader.
>>>>>>>>
>>>>>>>> Can you please point me to a set of bundles to use Johnzon JSON-B in OSGi?
>>>>>>>>
>>>>>>>> With regards,
>>>>>>>> Markus
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jean-Baptiste Onofré
>>>>>>> [hidden email]
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> [hidden email]
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> [hidden email]
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com