Hi David, That was quick :-)
Yes, I can confirm that running the patched version works. - Built spi-fly-core. - Changed spi-fly-dynamic-bundle pom.xml to point to the newly build org.apache.aries.spifly.core-internal 1.0.2-SNAPSHOT and built spi-fly-dynamic-bundle - The new spi-fly-dynamic-bundle now detects services providers in a jar/bundle that was previously ignored. -- Sten On Mon, Jan 26, 2015 at 1:23 PM, David Bosschaert <[email protected]> wrote: > Hi Sten, > > Thanks for pointing this out! > > I've created https://issues.apache.org/jira/browse/ARIES-1289 > And committed a fix that simply removes that check as you point out it > is unnecessary: > http://svn.apache.org/viewvc?view=revision&revision=1654765 > > Maybe you can check that this works for you. If so we can prepare a > release of SPI Fly with the fix. > > Best regards, > > David > > On 26 January 2015 at 11:55, Sten Nordstrom <[email protected]> wrote: >> Hi, >> >> ProviderBundleTrackerCustomizer.java in >> /repos/asf/aries/trunk/spi-fly/spi-fly-core/src/main/java/org/apache/aries/spifly/ProviderBundleTrackerCustomizer.java >> checks if the directory entry META-INF/services exists in the bundle, >> before actually reading the entries in the directory. If the check >> fails the addingBundle method will return null. >> >> The check occurs in lines 109-111 of ProviderBundleTrackerCustomizer.java: >> >> URL servicesDir = bundle.getResource("/" + METAINF_SERVICES); >> if (servicesDir == null) >> return null; >> >> It seems to me that this check is problematic as the spec for >> bundle.getResource says: >> >> "Note: Jar and zip files are not required to include directory >> entries. URLs to directory entries will not be returned if the bundle >> contents do not contain directory entries." >> >> A missing directory entry would cause ProviderBundleTrackerCustomizer >> to ignore any service providers in that bundle. It seems to me that >> the check is unneccessary as the next code-line is >> bundle.findEntries(METAINF_SERVICES, "*", false); which should work >> regardless of the directory exists or not. >> >> I encountered this issue while editing an existing jar by hand, after >> which spi-fly did not detect any service entries. Stepping through the >> debugger showed that the method as exited at line 111. Some quick >> testing gives that the linux zip command generates directory entries, >> however Windows builtin zip and the IZarc tool for windows do not. The >> JDK jar tool generates entries, so a jar built by a normal build >> process would not have this problem. >> >> best regards, >> >> -- Sten
