Hi Bartek, That's absolutely fine. This is an experimental component so we have to play around with various ideas.
I'll dive a little deeper and see what kind of manifests I would like best. In the mean time I'm experimenting with migrating the weaving stuff to use the RFC 159 weaving hook support. This is available in Eclipse 3.7. I'll store my work as-is in the spi-fly/contrib directory to allow further discussions around that... Once I have a better idea of how to go forward, we can merge it with the rest of the spi-fly codebase. Cheers, David On 3 November 2010 23:57, Bartosz Kowalewski <[email protected]> wrote: > Hi David, > > Honeslty, I'm to be blamed for these mechanisms :-). They were introduced > in the huge patch attached to ARIES-373. I thought that the fact that you > applied this patch means that you had approved those changes ;-). > > More seriously, I agree that this approach is complex and has lots of > drawbacks. The main issue is that there is no well-defined mapping between > service ids and these human readable API names that are used as a name of > the path element inside the header. This causes some weird strategies to > looking up implementations to be used on the SPI consumer side. > > The approach that we're now discussing was just a proposal, but let me > explain why I introduced this. There are two main reasons: > > 1) Some APIs load more than one file with SPI configuration. In other words, > they use many SPI (or SPI-like) service ids. Javamail is a good example of > such an API. > If we drop these human readable path element names and service id is used > instead, we would need to add many path elements for a single implementation > of a given API. > > 2) Human readable names let us hide all those complex service ids inside the > SPI provider bundles. The number of SPI providers will be relatively small, > so it's not a problem to expose the complexity of SPI Fly to people that > create (bundle) those. However, the number of bundles that are SPI consumers > will be much, much greater. > I think that being forced to add a header like > SPI-Consumer: javamail.default.providers;name="sun" > to your bundle once you need to use a specific impl version might cause > people to abandon using SPI-Fly and try something more straightforward (i.e. > rebundled APIs shipped with ServiceMix). > > As I said, each approach has some pros and cons. We just need decide which > approach has least significant disadvantages. > > One more thing: I think that the approach with SPI-Provider header without > any contents might be too simplistic. It will force us to either drop the > feature that enables SPI consumers to specify the name of the preferred > implementation or create some rules for generating implementation name for > the given SPI provider on the basis of bundle name and bundle version. > > Best regards, > Bartek > > David Bosschaert wrote the following on 11/3/2010 5:33 PM: >> >> Hi all, >> >> I'm currently looking at the SPI-Fly component again and rationalizing >> the SPI-Provider header. Currently the SPI-Provider header in the code >> base has two required attributes: provider-name and service-ids. >> >> In the code I found the following comment: >> // Format of each path element: >> // api1Name;provider-name="myimpl2";service-ids="myserviceId" >> >> // An example below. >> // Please note: >> // 1. The service-ids attribute holds a list of ids that will be >> // used when searching META-INF/services/. In other words >> // this will be the name of the class that will be passed to >> // ServiceLoader.load(). >> // 2. A single bundle can provide implementations for many APIs >> // - there might be many api names in a single SPI-Provider >> // header. >> >> // Sample: >> // jaxb;provider-name="xerces123";service-ids="javax.xml.bind.JAXBContext" >> >> I'm a little puzzled by this. I can see that provider-name could be >> useful in that it would be an additional service property. In the >> sample above, what would the relation between service-ids and the >> initial 'jaxb' piece? Should it not be something like >> SPI-Provider: javax.xml.bind.JAXBContext;provider-name="xerces123" ? >> besides, JAXB is probably a bad example because JAXB doesn't follow >> the common pattern in that the files in >> META-INF/services/javax.xml.bind.JAXBContext don't list >> subclasses/implementations of JAXBContext. >> >> So anyway. I don't understand the function of 'service-ids' and I >> think that provider-name should be an optional attribute. >> So you could have the following headers (examples): >> SPI-Provider: javax.xml.parsers.DocumentBuilderFactory >> SPI-Provider: >> javax.xml.parsers.DocumentBuilderFactory;provider-name="Xerces 2.10" >> SPI-Provider: >> >> javax.xml.parsers.DocumentBuilderFactory,org.apache.xerces.jaxp.SAXParserFactory >> We could even go for a more generic approach that allows arbitrary >> service properties to be specified: >> SPI-Provider: >> javax.xml.parsers.DocumentBuilderFactory;properties="provider-name:Xerces >> 2.10;my-other-prop:foobar" >> >> I think we could also consider having a simple header: >> SPI-Provider: true >> which would inspect the META-INF/services directory and register >> services for all providers it finds there... >> >> Thoughts anyone? >> >> David >> >
