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
<maggu2...@gmail.com>:
>
> 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é
> <j...@nanthrax.net>:
> >
> > 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é
> > >>> <j...@nanthrax.net>:
> > >>>>
> > >>>> 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é
> > >>>> jbono...@apache.org
> > >>>> http://blog.nanthrax.net
> > >>>> Talend - http://www.talend.com
> > >>
> > >> --
> > >> Jean-Baptiste Onofré
> > >> jbono...@apache.org
> > >> http://blog.nanthrax.net
> > >> Talend - http://www.talend.com
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com

Reply via email to