I haven't tried it with this particular API, but did play with it in the context of the sun.misc.Service API (which I believe is used as an implementation of the API you're using). In that case it was indeed needed to do something special (although I can't quite remember what it was ;).
If you can share a small test scenario of what you're trying to do I would be happy to take a look. Cheers, David On 13 April 2012 19:09, Bert Frees <bertfr...@gmail.com> wrote: > Thanks. I decided to upgrade to Equinox 3.7. Everything builds now. For some > reason though, the services in the provider-JAR are not detected. I must be > doing something wrong. I will read through the documentation again and I > will let you know when I got it figured out. > Thanks for all the help, > Bert > > > > On 13-apr-12, at 15:27, David Bosschaert wrote: > >> The dynamic support requires the OSGi WeavingHook which was introduced >> in Core 4.3, so that would need Equinox 3.7 or newer. >> >> You should be able to get things to work with the static weaving >> support. I personally don't think it's a big deal, you simply run your >> consumer bundle through the weaver tool, and then it should work in >> Equinox 3.6 (or any other Core 4.2 compliant container). >> >> See the Use with Static Weaving section here: >> http://aries.apache.org/modules/spi-fly.html >> >> The only difference between static and dynamic weaving is that with >> static weaving the bytecode modifications to insert the TCCL >> instructions are put in the bundle jar file, while with dynamic >> weaving they are inserted at runtime before the class is loaded. >> >> Hope this helps, >> >> David >> >> On 13 April 2012 14:06, Bert Frees <bertfr...@gmail.com> wrote: >>> >>> Thanks for the help! I guess I should've had a better look at the >>> documentation :) >>> >>> Now I hit the following problem: the requirement "org.osgi.framework >>> [1.6.0,2.0.0)" cannot be satisfied. The project I'm working on uses >>> Equinox >>> 3.6.1... Do we need to update to a newer version or is there another way >>> around it (apart from using the static bundle)? >>> >>> Thanks, >>> Bert >>> >>> >>> >>> On 04/13/2012 08:29 AM, David Bosschaert wrote: >>>> >>>> >>>> Hi Bert, >>>> >>>> Yes, although I haven't tried it with this particular API, it should >>>> work. >>>> >>>> Assuming that the method in that class you will be using is >>>> lookupProviders() you'd specify as a manifest header in the consumer >>>> bundle: >>>> SPI-Consumer: javax.imageio.spi.ServiceRegistry#lookupProviders >>>> >>>> On the provider side it should be enough to specify the following >>>> manifest header: >>>> SPI-Provider: * >>>> >>>> Let us know how you get on! >>>> >>>> Best regards, >>>> >>>> David >>>> >>>> On 12 April 2012 20:03, Bert Frees<bertfr...@gmail.com> wrote: >>>>> >>>>> >>>>> Hello, >>>>> >>>>> I'm interested in using Spi Fly in my project. I would like to make an >>>>> OSGi >>>>> bundle out of a JAR. Because the JAR was built for Java 1.5, it uses >>>>> javax.imageio.spi.ServiceRegistry instead of java.util.ServiceLoader. >>>>> Will >>>>> Spi Fly treat ServiceRegistry.lookupProviders() calls the same way it >>>>> treats >>>>> ServiceLoader.load() calls? >>>>> >>>>> Thanks, >>>>> /Bert >>> >>> >>> >
