Hi, Spring-Metrics is trying to be a good OSGI citizen and has added the following Manifest headers:
Provide-Capability: osgi.serviceloader;osgi.serviceloader=com.ryantenney.metrics.spring.reporter.ReporterElementParser Require-Capability: osgi.extender;filter:="(osgi.extender=osgi.serviceloader.registrar)" This seems to be correct as the relevant ReporterElementParser Service Loader Services get exposed as OSGI Services when the bundle is loaded. (SPI Fly is installed and loaded before Spring Metrics) However when Spring DM parses the application context the Spring Metrics XML extensions tries to load its own services but this fails; none are found. To me it seems that Spring-Metrics also has to be a consumer of its own services for dynamic weaving to work properly. This would require headers similar to Provide-Capability: osgi.serviceloader;osgi.serviceloader=com.ryantenney.metrics.spring.reporter.ReporterElementParser Require-Capability: osgi.serviceloader;filter:=“(com.ryantenney.metrics.spring.reporter.ReporterElementParser)”;cardinality:=multiple, osgi.extender;filter:=“(|(osgi.extender=osgi.serviceloader.registrar)(osgi.extender=osgi.serviceloader.processor))," (I have simply tried to merge the headers from Spring Metrics with what I found on the SPI Fly home page) Before I start filing changes to Spring Metrics it would be good if somebody could please help me with the following questions: Can a bundle be both a provider and consumer of its own service loader services? Can the osgi.extender capability have multiple values using the LDAP filter syntax as seen in my example? Or do you simply repeat the capability multiple times? Is static weaving a better option than dynamic weaving? Is there another way to make Spring Metrics work with Spring DM? Any feedback is welcome! Cheers, Chris PS I am currently on ServiceMix 5.4.3 and thus Karaf 4.3.1 which seems to indicate that dynamic weaving of service loader calls using SPI Fly should work
signature.asc
Description: Message signed with OpenPGP using GPGMail
