Description

When a service provider is compiled into a jar, it must provide files in META-
INF/services. When a jar -i is run on that file, the META-INF/services
directory is not added to the directory list in META-INF/INDEX.LIST. When this
jar is used, the appropriate service providers are not found. When I don't
create the index in the jar, the service provider is found correctly.

To reproduce the problem, you can try with any jar that includes a service
provider or use tritonus:
1. Download the latest CVS version of Tritonus, fromhttp://cvs.sourceforge.net/cvstarballs/tritonus-cvsroot.tar.gz.
2. build it (on linux) with "make compileinitial && make install"
3. cd test ; make MpegPlayer.java
4. java MpegPlayer "mp3file.mp3" should run fine, or at least NOT give the
error that the conversion is not supported.
5. jar -i ../dist/tritonus_core.jar
6. run again the MpegPlayer and the service provider isn't found, with an
UnsupportedAudioFileException.

Looking at the source code of jar/sun.misc.JarIndex:187:
if (fileName.startsWith("META-INF")) {
continue;
}
Everything inside META-INF is not included in INDEX.LIST. I think the service
provider files should be included in INDEX.LIST, as they are searched by the
classloader.
(Review ID: 111540)
======================================================================

Issue Links

duplicates

JDK-6732405Jar indexing fails to include META-INF in index so service provider config fails

Activity

It would have been better to locate services somewhere other than
META-INF, since they are indeed searched for by class loaders and are
in no sense meta information at the level of jar file structure. Even
that wouldn't have fully eliminated the problem, though, since there
are numerous other offenders putting property files, other
subdirectories, etc. into META-INF.

There is no way to determine with complete accuracy which files in
META-INF are part of the jar file's infrastructure and needn't be
indexed. We could reasonably exclude top-level ".SF", ".DSA", and ".RSA"
files (signature files and signature blocks). But in theory a new
signature algorithm could be used with a new (and unpredictable)
suffix.

Given that, along with the fact that there's no harm done in
having a superfluous "META-INF" entry in the index, it's probably
not worth going to much effort trying to figure out what to
exclude. Maybe just exclude the manifest file and the index
file itself, and index anything else.

Scott Seligman (Inactive)
added a comment - 2003-02-24 16:00 BT2:EVALUATION
It would have been better to locate services somewhere other than
META-INF, since they are indeed searched for by class loaders and are
in no sense meta information at the level of jar file structure. Even
that wouldn't have fully eliminated the problem, though, since there
are numerous other offenders putting property files, other
subdirectories, etc. into META-INF.
There is no way to determine with complete accuracy which files in
META-INF are part of the jar file's infrastructure and needn't be
indexed. We could reasonably exclude top-level ".SF", ".DSA", and ".RSA"
files (signature files and signature blocks). But in theory a new
signature algorithm could be used with a new (and unpredictable)
suffix.
Given that, along with the fact that there's no harm done in
having a superfluous "META-INF" entry in the index, it's probably
not worth going to much effort trying to figure out what to
exclude. Maybe just exclude the manifest file and the index
file itself, and index anything else.
###@###.### 2003-02-25

Defect Conversion BT2 (Inactive)
added a comment - 2004-06-10 19:45 BT2:WORK AROUND
Name: boT120536 Date: 01/25/2001
I was able to fix the problem by manually adding a line "META-INF/services" in
INDEX.LIST.
======================================================================