>>>>> Łukasz Dywicki <[email protected]>: > I haven't dug into spi-fly for a while, can you point me which part of > its code handle declared capabilities so I can have a look?
Well, I have never looked into the spi-fly source code, so pointing you there is not something I can do, without a lot of effort. :-) But what I can do is point you at the documentation for declaring a service loader capability https://aries.apache.org/documentation/modules/spi-fly.html#specconf And also the OSGi spec version of the service loader adapter: https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.loader.html > My basic understanding of Provide and Require-Capability headers is > that these are primarily hints for osgi resolver to gather > dependencies on layer other than import/export packages. My understanding, so far(*), is this: 1. The SPI Service Provider Interface is a plugin mechanism that is part of the JRE 2. The SPI is used for various systems in the JRE, e.g. the ImageIO mechanism for loading and saving various image formats 3. In the case of ImageIO, the SPI makes it possible to replace the implementations of the plugins used to read and write images, i.e. replace the builtin image readers/writers, with the ones from apache commons imageio or the ones from TwelveMonkeys (I am currently trying to use TwelveMonkeys and in the process, provide a PR to make TwelveMonkeys OSGi-compliant) 4. The service loader mediator is an extension mechanism to OSGi and not part of OSGi proper 5. Apache Aries SPI fly is an implementation of the service loader mediator 6. To use the service loader, the OSGi bundle exporting an SPI plugin needs to add two headers: 1. A Require-Capability header that loads osgi.serviceloader.registrar as an osgi.extender 2. A Provide-Capability header that tells the osgi.serviceloader that the bundle contains implementation(s) of the service interface 7. The bundle(s) using the capability need to add a Require-Capability header that will load the osgi.serviceloader.processor as a service and tell the serviceloader to load all instances of the service interface Based on that understanding I have added the following headers to the manifest.mf of the jar/bundle providing the JPEG reader/writer plugin: Provide-Capability: osgi.serviceloader;osgi.serviceloader="javax.imageio .spi.IIOServiceProvider" Require-Capability: osgi.extender;filter:="(osgi.extender=osgi.servicelo ader.registrar)",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" Tool: Bnd-6.3.1.202206071316 And in my bundle trying to replace the standard JRE ImageIO I have added the following header: Require-Capability: osgi.extender;filter:="(osgi.extender=osgi.servicelo ader.processor)",osgi.service;filter:="(objectClass=javax.sql.DataSourc e)";effective:=active,osgi.service;filter:="(objectClass=org.osgi.servi ce.log.LogService)";effective:=active,osgi.serviceloader;filter:="(osgi .serviceloader=javax.imageio.spi.IIOServiceProvider)";cardinality:=mult iple,osgi.extender;filter:="(&(osgi.extender=osgi.component)(version>=1 .5.0)(!(version>=2.0.0)))",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version= 17))" In the JPEG plugin, this caused the maven-bundle-plugin (I think) to discover two plugin implementations and create the files META-INF/ services/ javax.imageio.spi.ImageReaderSpi javax.imageio.spi.ImageWriterSpi Where the javax.imageio.spi.ImageReaderSpi and javax.imageio.spi.ImageWriterSpi contains the fully qualified classnames of classes in the imageio-jpeg.jar bundle: com.twelvemonkeys.imageio.plugins.jpeg.JPEGImageReaderSpi com.twelvemonkeys.imageio.plugins.jpeg.JPEGImageWriterSpi And that, I thought, looked kind of promising. Unfortunately it didn't work. My code inside karaf still picked the JRE's version of the JPEGImageReader when I looked at it in the debugger. And when I looked for spi-fly messages in the karaf.log, I found that spi-fly was trying to consolidate my bean AlbumEntry with ResultSet (from JDBC) and complaining that the two didn't share a common superclass and outputting a lot of errors around that (I don't know if this is the reason TwelveMonkeys fails to register but it's currently my best bet). https://issues.apache.org/jira/browse/ARIES-2110 The error messages have something to do with dynamic weaving which both the spi-fly documentation and the OSGi spec talks about. But why it triggers here, and why it tries to unify my bean with the JDBC ResultSet, I have no idea. I have a method that takes a ResultSet as an argument, and return an AlbumEntry bean, but why that would make something think the two are the same and try to unify them I don't know. Anyway: this weird error currently blocks my attempts at providing an OSGi-fication PR for TwelveMonkeys. - Steinar (*) But this understanding may be wrong...
