Previously, DevTools assumed that the TCCL was a URLClassLoader
when trying to determine the URLs that it should examine to determine
the locations that should be watched for triggering a restart. This
fails on Java 9 as the TCCL is not a URLClassLoader.
This commit updates the logic that determines the changeable URLs to
fall back to examining the JVM's class path when the TCCL is not a
URLClassLoader, typically because the application is running on Java
9. This fall back isn't a direct equivalent of the behaviour on Java 8
as the class path of the TCCL and the class path with which the JVM
was launched may not be the same. However, I consider the fix to be
reasonable for two reasons:
1. In reality, the class path of the TCCL and the class path with
which the JVM was launched are the same.
2. There appears to be now to get the URLs on the class path of the
TCCL on Java 9. There is a URLClassPath field, however Java 9's
access restrictions prevent us from using it even if we resort to
reflection.
Closes gh-10454
Previously, in the DevTools integration tests, portions of a File's
path were used to create the name of a jar entry. On Windows this
resulted in the entry containing \ characters. As a result the
directory structure was incorrect and the classes could not be loaded
from the jar.
This commit ensures that any \ characters are replaced with /
characters.
See gh-7782
Previously, we just waited for the file to exist before trying to read
the port from it. This left a window where the file existed but its
contents had not be written which could result in a
NumberFormatException.
This commit now waits for the file to have a length that is greater
than zero.
See gh-7379
Previously, remote DevTools only correctly supported modifying
existing classes. New classes that were added would be missed, and
deleted classes could cause a failure as they would be found by
component scanning but hidden by RestartClassLoader.
This commit introduces a DevTools-specific ResourcePatternResolver
that is installed as the application context's resource loader. This
custom resolver is aware of the files that have been added and
deleted and modifies the result returned from getResource and
getResources accordingly.
New intergration tests have been introduced to verify DevTools'
behaviour. The tests cover four scenarios:
- Adding a new controller
- Removing an existing controller
- Adding a request mapping to a controller
- Removing a request mapping from a controller
These four scenarios are tested with:
- DevTools updating a local application
- DevTools updating a remote application packaged in a jar file
- DevTools updating a remote application that's been exploded
Closes gh-7379