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 > <[email protected]>: >> >> 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é >> <[email protected]>: >>> >>> 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é >>>>>> <[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 >>> >>> -- >>> 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
