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é > <[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
