JarFileArchive writes every app's unpacked libraries to the same location

[ViktorRiabinin]

There are two exacutable jars that are run with different owners. Both of them contain libraries that should be unpacked. parameter of spring-boot-maven-plugin is used.

Process that starts first creates temp folder and puts extracted jars into it. Process that starts second can't write its jars in the same folder since it doesn't have write permission.

Name of temp folder - spring-boot-libs - is hardcoded in file "JarFileArchive.java" and cannot be specified for different projects.

I can solve this problem running all jars with similar owner. Nevertheless, I'd like to ask - is it planned to make name of temp folder configurable?

[wilkinsona]

I think that's a bug. Two applications shouldn't share the same unpack location. Differing permissions is one problem. The possibility of one application overwriting another's libs is another. I'm not sure we'll make the temp folder configurable. I'd hope that automatically using one temp folder per application would be sufficient.

[philwebb]

One possible side-effect of this change is that unpack now needs to occur on each run. Previously if a file existed and was the same size no unpacking occurred. We could consider using an approach similar to org.springframework.boot.ApplicationTemp from 1.3.

[philwebb]

Reopening to consider if the unpack overhead will be a problem.

[wilkinsona]

I ran the Jersey 1 sample with some added diagnostic around the unpacking. The time taken in order of unpacking:

Artifact	Size	Time
jersey-servlet-1.13	123KB	13ms
jersey-server-1.13	586KB	4ms
jersey-core-1.13	455KB	2ms

I guess it gets faster despite the size increase thanks to the JIT. Given that it's unpacking more than 1MB in less than 20ms I'm not sure it's worth making this any more complex.

I'd missed the use of the checksum in the filename. If we keep the current directory structure we could remove that checksum from the filename as it's no longer needed.