Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

INDEX.LIST uses incorrect jar names [SPR-6383] #11049

Closed
spring-projects-issues opened this issue Nov 18, 2009 · 11 comments
Closed

INDEX.LIST uses incorrect jar names [SPR-6383] #11049

spring-projects-issues opened this issue Nov 18, 2009 · 11 comments

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Nov 18, 2009

Matt Goldspink opened SPR-6383 and commented

The INDEX.LIST files generated in the jars have the incorrect jar names in them which don't match up to those in download for 3.0 RC2. For example the aop jar contains:

JarIndex-Version: 1.0

org.springframework.aop.jar
org
org/springframework
org/springframework/aop
org/springframework/aop/aspectj
org/springframework/aop/aspectj/annotation
org/springframework/aop/aspectj/autoproxy
org/springframework/aop/config
org/springframework/aop/framework
org/springframework/aop/framework/adapter
org/springframework/aop/framework/autoproxy
org/springframework/aop/framework/autoproxy/target
org/springframework/aop/interceptor
org/springframework/aop/scope
org/springframework/aop/support
org/springframework/aop/support/annotation
org/springframework/aop/target
org/springframework/aop/target/dynamic
overview.html

but the actual jar in the zip file downloaded is: org.springframework.aop-3.0.RC2.jar

I'm not sure what problems this causes but one of our users pointed this out a while back in rc1.


Affects: 3.0 RC2

Issue Links:

  • #13846 application context created within java web start application triggers many http requests for non existing resorces ("is duplicated by")

Referenced from: commits 2fe74a4

11 votes, 15 watchers

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 18, 2009

Jeffrey Sinclair commented

From what I recall the issue was that the Eclipse debugger uses the information in the jar index to speed up lookups. If the physical jar name does not match what is in the index, FileNotFoundExceptions appear whilst debugging. Personally I don't think the jar name should be inside the index since it is fragile when it comes to symlinking, however this looks to be what is expected, hence if spring aligns the index correctly, it would avoid this annoyance in Eclipse.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 29, 2009

Costin Leau commented

The index seems to be created by Spring Build, through task 'jar' defined in file common/artifact.xml. I couldn't find any overriding property so rather then copy-pasting the section from SB, I'm assigning the issue to BenH to work his build magic.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 29, 2009

nebhale commented

The name that shows up in that index is the proper name for the file when the indexing is done. That file changes name many times (ivy upload, maven upload, ivy download, maven download, packaging, etc) so I don't think that we can keep it in sync properly and if we could it would involve re-indexing the file a load of times.

In practice the most important place that indexing speeds things up is in classloading in the VM and there doesn't appear to be a problem.

I (and the team I work with) deal with those JARs in Eclipse every day and have never seen the error you are reporting. Can you please add some additional detail about this issue (error stack traces or screenshots would be good) as well as detail about the version of Eclipse that you're using.

Thanks.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 4, 2010

Jeffrey Sinclair commented

Ben, apologies for the delay in getting back to this. From what I recall we were using Eclipse 3.4 and SunJDK 1.6.0_14. I've tried this again with: Eclipse 3.5.2, SunJDK 1.6.0_16 and cannot replicate this issue. I know there was a problem with breakpoints not being honored in SunJDK 1.6.0_14 which might have contributed to the problem or perhaps there was an update to the way Eclipse indexes the jars. Either way I would suggest we close this issue and if it happens again we will try to provide a full reproduction.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 2, 2010

Julien HENRY commented

It seems this issue is breaking my webstart application. Each time I perform a ClassLoader.getResource() and for each spring JAR, webstart will send a request to the server and wait for the 404:
GET http://myserver:8080/webstartapp/org.springframework.core.jar HTTP/1.1
HTTP/1.1 404 Not Found

Because I have more than 10 spring jars in my project, each getResource() call will lead to more than 10 network requests. As a result I have an algorithm that take 6 seconds when ran outside of webstart, but take more than 1 minute when ran in webstart.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Feb 11, 2011

Ivan dal Bosco commented

Dear all,

Here is a likely consequence of this error.

In Eclipse, when I run my classes in debug mode, execution always stops on a FileNotFoundException raised in sun.misc.URLClassPath$JarLoader.getJarFile(java.net.URL). The value of the URL argument is:
file:/C:/Java/maven-repository/org/springframework/spring-context/3.0.5.RELEASE/org.springframework.context.jar
Indeed, my file spring-context-3.0.5.RELEASE.jar contains a META-INF/INDEX.LIST file whose line 3 is
org.springframework.context.jar
which is most probably incorrect.

To overcome this trouble, I simply have to click twice on Resume (F8), so the error is just a minor nuisance, although it is systematic.

If I edit my spring-context-3.0.5.RELEASE.jar and remove the line above, the trouble vanishes.

Best regards,

Ivan

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 18, 2011

Nathan Waldman commented

As Julien Henry mentioned above, for webstart applications with poor internet connectivity, this can cause significantly degraded performance. Is there an option to reference non-indexed versions of the spring jars in maven?

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 24, 2011

Valentin Rocher commented

We found a workaround to this here :

  • create an empty maven project with all the problematic spring jars as dependencies
  • use the maven shade plugin to create a meta-jar with your spring jars (don't forget to exclude the INDEX.list)
  • in place of referencing spring jars, reference your dummy maven project

The POM for this project is something like that :

<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>3.0.2.RELEASE</version>
<exclusions>
<exclusion>
<artifactId>commons-logging</artifactId>
<groupId>commons-logging</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>3.0.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>3.0.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>3.0.2.RELEASE</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<filters>
<filter>
<includes>
<include>**</include>
</includes>
<excludes>
<exclude>META-INF/MANIFEST.MF</exclude>
<exclude>META-INF/INDEX.LIST</exclude>
<exclude>overview.html</exclude>
</excludes>
</filter>
</filters>
<transformers>
<transformer
implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
<resource>META-INF/spring.handlers</resource>
</transformer>
<transformer
implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
<resource>META-INF/spring.schemas</resource>
</transformer>
<transformer
implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
<resource>META-INF/spring.tooling</resource>
</transformer>
</transformers>
<createSourcesJar>true</createSourcesJar>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 4, 2012

Lukasz Rozek commented

here is related issue to the problem: https://jira.springsource.org/browse/SPR-9208
which causes multiple 404, and slows down startup of application every run.

If maintaining (reindexing) file name in index.list is overwhelming, can you consider giving up creating this index file when packaging ??
According to http://docs.oracle.com/javase/6/docs/technotes/guides/jar/jar.html#JARIndex it seems that you gain benefit of indexing, only when you index.list for multiple jars and put it to the single "main" jar

"The existing jar tool is enhanced to be able to examine a list of jar files and generate directory information as to which classes and resources reside in which jar file. This directory information is stored in a simple text file named INDEX.LIST in the META-INF directory of the root jar file. When the classloader loads the root jar file, it reads the INDEX.LIST file and uses it to construct a hash table of mappings from file and package names to lists of jar file names. In order to find a class or a resource, the class loader queries the hashtable to find the proper jar file and then downloads it if necessary"

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 13, 2012

Chris Beams commented

Resolved by simply removing INDEX.LIST generation. This does not happen in the new Gradle-based build under Spring 3.2.x, and for Spring 3.1.x versions beginning with 3.1.2, INDEX.LIST will be ommitted altogether to avoid these problems.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 13, 2012

Chris Beams commented

commit 2fe74a4ef0cb8f667c4fa342e649bc75da4d8a6a (HEAD, springsource/3.1.x, 3.1.x)
Author: Chris Beams <cbeams@vmware.com>
Date:   Fri Apr 13 16:46:26 2012 +0300

    Eliminate INDEX.LIST from Spring jar META-INF dirs
    
    The contents of this file could be problematic as they were generated
    by spring-build with "org.springframework.core.jar" EBR-style naming,
    but this naming is incorrect when dealing with Maven-central style
    artifacts, e.g. spring-core.jar.
    
    While a well-formed INDEX.LIST may speed up classloading, the simplest
    solution to the issues listed below is simply to eliminate the file.
    This also means consistent treatment across 3.1.x and 3.2.x artifacts,
    as the new Gradle build in 3.2.x does not create these index files.
    
    Issue: SPR-6383, SPR-9208

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant