To use PropertiesLauncher instead of JarLauncher in an
executable JAR we have provided tooling support. In Maven
(using the starter parent to default some of the settings):
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<layout>ZIP</layout>
</configuration>
</plugin>
in Gradle:
apply plugin: "spring-boot"
springBoot {
layout = 'ZIP'
}
}
[Fixes#58837492] [bs-330] Add tooling for PropertiesLauncher
PropertiesLauncher can now be used to run an executable jar, and by
default it will pick up nested archives in lib/ (where the Boot
tools puts them). User can provide loader.path (colon-separated)
to change the nested path.
[#58837492] [bs-330] Add tooling for PropertiesLauncher
...otherwise you can see cryptic NoClassDefFound errors
because the application class was loaded from the parent
on the file system, but then it doesn't have access to the
child loaders nested jars.
E.g. with a prefix spring.jpa.hibernate. we want naming-strategy and
namingstrategy to be resolvable. It wasn't working before this change
because the whole property path was being manipulated, where you
actually need to manipulate the prefix and suffix separately.
Previously, simple @Grab annotations only worked on classes. This commit
updates the simple @Grab support so that they can be used on anything
that can be annotated with @Grab.
The simplified @Grab support relies upon springcli.properties having
been generated. This commit adds an M2E lifecycle mapping for the
antrun plugin so that springcli.properties is generated as part of an
Eclipse build, thereby making it easier to run tests in Eclipse that
rely upon the simplified @Grab support.
Since ServerProperties had primitive properties for port (in
particular) it was not possible to check when applying those
properties if the user had actually changed the value. This
in turn meant that a custom EmbeddedServletContainerFactory
could not set the default values.
Fixed by making int properties of ServerProperties into
Integer and checking for null before setting on the
container factory.
Fixes gh-84
Previously, LocalM2Resource used the pom's packaging configuration to
determine the suffix of the file that it should look for, e.g. if
the pom's packaging was jar, it would look for a file with a .jar
suffix in artifactExists(). This logic fails for artifacts with bundle
packaging as it would look for a .bundle file rather than a .jar file,
fail to find the file, and incorrectly report that the artifact does not
exist.
This commit updates LocalM2Resource to look for a file with a .jar
suffix when the packaging configuration in the pom is bundle.
Fix LaunchedURLClassLoader to only enumerate resources from the
rootLoader and the URLs.
Commit cd2c189 (Support javaagent instrumentation with loader) added
a parent classloader and used filtering in the loadClass() method
to ensure classes were loaded from the appropriate location. The change
in parent means that locally packaged resources are found twice, once
from the parent, and once from the self archive URL.
LaunchedURLClassLoader now overrides getResource and getResources to
filter out the parent classloader and instead only add resources from
the root classloader and the URLs.
Issue: #56232870
In some cases the websocket communication fails and Snake#sendMessage throws an exception.
In that case the send loop is interrupted and later clients are not update.
- Look for JUnit test symbols, and add JUnit automatically
- Look for Spock test symbols, and add Spock automatically
- Based on what test libraries were used, invoke relevant embedded testers
and accumulate results
- Make it so that multiple testers can be invoked through a single 'test' command
- Print out total results and write out detailed trace errors in results.txt
- Update based on the new artifact resolution mechanism