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.

Sign up for GitHub

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

Jump to bottom

Loader Tools: unpacking a library alters its position in the classpath #11695

Closed
brenuart opened this issue Jan 19, 2018 · 2 comments
Closed

Loader Tools: unpacking a library alters its position in the classpath #11695

brenuart opened this issue Jan 19, 2018 · 2 comments
Assignees
@wilkinsona
Labels
type: bug A general bug
Milestone
2.0.0.RC2

Comments

@brenuart
Copy link
Contributor

The order of libraries on the runtime classpath should match the order they were initially added in the fat jar.
The Repackager adds libraries in the following order:

  1. unpack libraries
  2. application classes
  3. other libraries
  4. loader classes

Marking a library as unpacked affects its position on the classpath - which is not expected.

See https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-loader-tools/src/main/java/org/springframework/boot/loader/tools/Repackager.java#L252-L267
See #9128 (comment)
@brenuart brenuart changed the title Loader: unpacking a library alters its position in the classpath Loader Tools: unpacking a library alters its position in the classpath Jan 19, 2018
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jan 19, 2018
@philwebb philwebb added type: bug A general bug priority: normal and removed status: waiting-for-triage An issue we've not yet triaged labels Jan 21, 2018
@philwebb philwebb added this to the 2.0.0.RC2 milestone Jan 21, 2018
@wilkinsona
Copy link
Member

wilkinsona commented Jan 31, 2018 •
edited
Loading

I've just reminded myself that the current ordering is deliberate (see #3444 for details). If we're going to fix this, we'll have to find a way to do so that doesn't introduce a regression.

wilkinsona added a commit that referenced this issue Jan 31, 2018
@wilkinsona
Align ordering of BootJar and BootWar archive entries
8f116f7 
Previously, the ordering of the entries in an archive produced by
BootJar was different to the ordering of the entries in an archive
produced by BootWar. The latter placed application classes before
any nested jars, whereas the former was the other way around.

This commit updates BootJar to use the same ordering as BootWar and
adds tests to verify that the ordering is the following:

1. Loader classes
2. Application classes (BOOT-INF/classes or WEB-INF/classes)
3. Nested jars (BOOT-INF/lib or WEB-INF/lib)
4. Provided nested jars in a war (WEB-INF/lib-provided)

The tests also verify that the position of a library is not affected
by it requiring unpacking.

See gh-11695
See gh-11696
@wilkinsona
Copy link
Member

The Gradle plugin is unaffected by this problem. I've added a test to verify that's the case in 8f116f7.

@wilkinsona wilkinsona self-assigned this Feb 1, 2018
wilkinsona added a commit that referenced this issue Feb 1, 2018
@wilkinsona
Ensure that TestJarFile uses insertion order for jar's entries
1d2b85b 
Previously, the order of the entries in a TestJarFile was determined
by the underlying file system rather than by the order in which
they were added. This could lead to unpredicatable ordering and
failures in tests that verify archive entry ordering.

This commit updates TestJarFile to add entries to the archive in
insertion order.

See gh-11695
See gh-11696
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@wilkinsona wilkinsona

Labels
type: bug A general bug
Projects
None yet
Milestone
2.0.0.RC2
Development

No branches or pull requests
4 participants
@philwebb @wilkinsona @brenuart @spring-projects-issues