Some libraries like aspectj are using findResource to see the raw
bytecode of a class. It will even call findResource for every method of
every class of beans that are post processed. This can be significant
performance hit on startup when LaunchedURLClassLoader and there are a
lot of nested jars.
See gh-3640
Fixes gh-4557
Previously, JarFileArchive would always unpack any entries marked for
unpacking to ${java.io.tmpdir}/spring-boot-libs. This could cause
problems if multiple Spring Boot applications were running on the same
host:
- If the apps are run as different users the first application would
create the spring-boot-libs directory and the second and subsequent
applications may not have write permissions to that directory
- Multiple apps may overwrite each others unpacked libs. At best this
will mean one copy of a jar is overwritten with another identical
copy. At worst the jars may have different contents so that some of
the contents of the original jar disappear unexpectedly.
This commit updates JarFileArchive to use an application-specific
location when unpacking libs. A directory beneath ${java.io.tmpdir} is
still used but it's now named <jar-file-name>-spring-boot-libs-<uuid>.
A loop, limited to 1000 attempts, is used to avoid problems caused by
the uuid clashing.
Closes gh-4124
When nested jars are being used, hasMoreElements requires opening a
connection for an entry in every nested jar. If that entry doesn't
exist, a FileNotFoundException is thrown to indicate that a particular
jar doesn't contain the requested entry. This exception is used to
indicate the lack of an entry and is then swallowed, i.e. its stack
trace is of no importance. This means that the performance of
hasMoreElements can be improved by switching on fast exceptions while
it's being called. When fast exceptions are switched on a general
purpose pre-initialized FileNotFoundException is thrown rather than
creating a new FileNotFoundException instance each time.
In certain situations, the use of fast exceptions as described above
can improve performance fairly significantly. The JRE's default SAAJ
implementation uses META-INF/services-based discovery for _every_
request that's handled by Spring Web Services. Each discovery attempt
results in hasMoreElements being called making its performance
critical to throughput.
See gh-3640
I think this is safe, judging by the integration tests, but I'm not
putting it in 1.2.x until we've had some feedback on it. The
integration tests actually had a bug that was masking this problem
because they were merging Properties from the whole classpath instead
of picking the first available resource (which is generally what
we do in Spring Boot applications for application.properties for
instance).
Fixes gh-3048
