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é > > <[email protected]>: > >> > >> 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é > >> [email protected] > >> http://blog.nanthrax.net > >> Talend - http://www.talend.com > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com
