This works, and feels like the right thing to do, since there is no
guarantee that extensions won't in turn use ServiceLoader for things
that we haven't yet anticipated.
Fixes gh-6829. Cc @wilkinsona in case he has an opinion.
Previously, CLI extensions where installed into the CLI's lib
directory which meant that they were on the class path of the app
class loader. Following the change to an executable jar's packaging,
this meant that they could not see classes in the CLI and a
ClassNotFoundException would result.
This commit updates the CLI to install extensions into lib/ext and
load commands using a new ClassLoader that has all of the jars in
lib/ext on its class path and that uses the launch class loader as
its parent.
Closes gh-6615
Where possible, code that previously synchronized on this (or on the
class in the case of static methods) has been updated to use an
internal monitor object instead. This allows the locking model that's
employed to be an implementation detail rather than part of the
class's API.
Classes that override a synchronized method continue to declare
the overriding method as synchronized. This ensures that locking
is consistent across the superclass and its subclass.
Closes gh-6262
Previously, the CLI would always use the class loader to try to locate
a source file. This was contrary to the SourceOptions javadoc which
states that the class loader is “used to try and load files that are
not found in the local filesystem”. This provide to be problematic on
Windows when a fully-qualified source file was supplied. The driver
letter colon slash (e.g. c:/) at the start of the path is considered
invalid for a class path resource by URLClassPath.Loader resulting in an
IllegalArgumentException being thrown.
A workaround for this URLClassPath behaviour was added in a71c9b5d. It
was removed as part of reworking LaunchedURLClassLoader to use a
conventional delegation model in 87fe0b2a. It was then reinstated in
cc140b2c. This work around is undesirable as it causes
LaunchedURLClassLoader’s behaviour to diverge from URLClassLoader’s
behaviour (this is contrary to the comments in the test added in
a71c9b5d which incorrectly tests the two class loader with different
class paths. If the two class loaders are created with the same class
path then their behaviour is the same).
This commit updates SourceOptions to make its behaviour match its
javadoc so that a search of the class path is only performed if the
filename doesn’t exist on the filesystem. Furthermore, when running on
Windows, if the filename is an absolute path no further searching is
performed as the path cannot reliably be used to search the class path
due to the behaviour of URLClassPath.Loader when given a path that
is an absolute file path on Windows. This ensures that the user is
presented with an error message indicating that the file could not be
found.
Closes gh-5650
State is accumulating unnecessarily in AST tranformation instances.
We can fix the ones we have implemented so far just by using a
local variable and passing it into the methods where it is used.
All the methods are private so this change is safe in a point release.
Fixes gh-5283
When an application is run as an executable archive with nested jars,
the application's own classes need to be able to load classes from
within the nested jars. This means that the application's classes need
to be loaded by the same class loader as is used for the nested jars.
When an application is launched with java -jar the contents of the
jar are on the class path of the app class loader, which is the
parent of the LaunchedURLClassLoader that is used to load classes
from within the nested jars. If the root of the jar includes the
application's classes, they would be loaded by the app class loader
and, therefore, would not be able to load classes from within the
nested jars.
Previously, this problem was resolved by LaunchedURLClassLoader being
created with a copy of all of the app class laoder's URLs and by
using an unconventional delegation model that caused it to skip its
parent (the app class loader) and jump straight to its root class
loader. This ensured that the LaunchedURLClassLoader would load both
the application's own classes and those from within any nested jars.
Unfortunately, this unusual delegation model has proved to be
problematic. We have seen and worked around some problems with Java
Agents (see gh-4911 and gh-863), but there are others (see gh-4868)
that cannot be made to work with the current delegation model.
This commit reworks LaunchedURLClassLoader to use a conventional
delegate model with the app class loader as its parent. With this
change in place, the application's own classes need to be hidden
from the app class loader via some other means. This is now achieved
by packaging application classes in BOOT-INF/classes (and, for
symmetry, nested jars are now packaged in BOOT-INF/lib). Both the
JarLauncher and the PropertiesLauncher (which supports the executable
jar layout) have been updated to look for classes and nested jars in
these new locations.
Closes gh-4897
Fixes gh-4868
It seems that the code for executing a groovy closure from the
OptionHandler is never executed and therefore not needed.
Removing the code gives the benefit that the Groovy-classes are not
needed if someone else wants to use the spring-boot-cli infrastructure to
run his own cli interface.
Closes gh-4411
Previously, MavenSettings used a FileProfileActivator with no
PathTransformer. If a settings.xml file contains a file-activated
profile this would result in an NPE within Maven. This was made worse
by the NPE not being included in the resulting failure message which
hampered diagnosis of the problem.
This commit updates MavenSettings to configure its FileProfileActivator
with a PathTransformer. It also improves the failure message that’s
created from any problems that are reported by Maven while determining
the active profiles to include a problem’s exception if it has one.
Closes gh-4826
Update exit code support to allow the ExitCodeGenerator interface to
be placed on an Exception. Any uncaught exception implementing the
interface and returning a non `0` status will now trigger a System.exit
with the code.
Fixes gh-4803
Ensure that Collections.isEmpty() is used to check if there are no
elements in a collections. This is more explicit and can be faster than
calling .size().
Closes gh-4783
The CLI application advertises `-cp` support but it appears that only
`--cp` is really supported. The fix for gh-178 forgot to update the
call to `getParser().parse(...)`.
See gh-178
Spring Initalizr now bundles a wrapper script for the build system. While
that wrapper has the necessary execute flag in the zip archive, that flag
is lost as the zip abstraction does not honor those.
The init command now makes sure to restore the execute flag on `mvnw`
and `gradlew` if necessary.
Unfortunately, this can't be tested as the Windows build would fail to
assert that the executable flag has been propertly set.
Closes gh-4392
Plugin authors can extend this class, provide missing methods,
and specify a BOM to add to the dependency management lookup
(i.e. dependencies by artifactId)
Certain Maven profile activator’s require access to System properties
to determine whether or not a profile should be activated.
JdkVersionProfileActivator is one such activator.
Prior to this commit, the presence of a Maven profile that was activated
based on the JDK in a bom imported using @DependencyManagementBom in the
CLI would trigger a failure as the JdkVersionProfileActivator could not
determine the version of Java on which it was running.
This commit updates the CLI to pass the JVM’s System properties to the
request to build a bom’s model so that those system properties can be
used by JdkVersionProfileActivator (and any other activators which need
them).
Given that Spring Boot uses java config accross the board, a new `value`
attribute is now aliased to the existing `classes` attribute such that
one could write the following:
@SpringApplicationConfiguration(MyConfig.class)
public class MyTest {}
Closes gh-3635
On start.spring.io, if you customize the artifactId it creates a zip file
with the same name. The `spring init` command did not have a similar
shortcut.
This commit updates the request to customize the artifactId if none is
set and a custom location was specified. Just as we check for the
presence of a dot to figure out if we have to extract the archive or not,
we check for it to generate an artifactId without an extension.
In practice, `spring init foo` creates a foo directory with a project
whose artifactId is `foo` and `spring init foo.zip` stores a foo.zip
file with the same project (i.e. the artifactId is `foo`).
Closes gh-3714
This commit enhances the CLI to use the repositories configured in the
profiles declared in a user's Maven settings.xml file during
dependency resolution. A profile must be active for its repositories
to be used.
Closes gh-2703
Closes gh-3483
Unfortunately, we have no other choice to flip the ignoreUnknownFields
attribute of `SecurityProperties` has many different target are now set
for that namespace outside the class. See gh-3445 for a potential way
to improve that.
Closes gh-3327
Previously, DefaultRepositorySystemSessionAutoConfiguration would
read the local repository configuration from settings.xml, but did
not perform any property interpolation. This would leave placeholders
such as ${user.home} as-is and result in the use of the wrong
location. To address this, the code that reads settings.xml has been
updated to provide the current System properties as a property
interpolation source.
RepositoryConfigurationFactory configures the local repository as a
"remote" repository when the local repository location has been
overridden. This allows spring grab to copy dependencies from the
local repository into the grab output location (configured via the
grape.root system property) rather than having to download them again.
This logic did not consider the customization of the local repository
location via settings.xml so the dependencies would be downloaded again.
To address this, RepositoryConfigurationFactory has been updated to
attempt to use the location configured in settings.xml, before falling
back to the default location.
The logic that reads settings.xml has deliberately been duplicated. It
could have been extracted into a separate class, but this is only a
temporary measure until gh-3275 is tackled. Duplication was deemed
preferable to adding a new public class in 1.2.x that we’d then want to
remove in 1.3.
Closes gh-3274
Remove explicit TestFailedException catch in CommandRunner and instead
rely on the fact that TestFailedException extends CommandException.
Fixes gh-3167
User can enable OAuth2 SSO by declaring the intent (@EnableOAuth2Sso)
and also configuring the client properties (spring.oauth2.client.*).
The spring.oauth2.sso.* are only needed to change the path for the
login (defaults to /login) - any other security configuration for the
protected resources can be added in a WebSecurityConfigurerAdapter
which carries the @EnableOAuth2Sso annotation.
* Automatically spin up Authorization Server and Resource Server
* Automatically configures method level security included OAuth2Expression handler
* Wrote extensive unit tests verifying default behavior as well as the auto-configuration backing off when custom Authorization/Resource servers are included
* Created org.springframework.boot.security.oauth2 subpackage to contain it
* Can also disable either resource of authorization server completely with a single property for each
* Print out the auto-generated secrets and other settings
* Added spring-boot-sample-secure-oauth2 to provide a sample that can be run and poked with curl as well as some automated tests.
* Make users ask for which servers to install by adding @Enable*
* User has to @EnableGlobalMethodSecurity instead of using properties files
Add Spring Security OAuth2 support to Spring Boot CLI
* Triggered from either @EnableAuthorizationServer or @EnableResourceServer
* Needs to have @EnableGlobalMethodSecurity to allow picking the annotation model.
* By default, comes with import support for @PreAuthorize, @PreFilter, @PostAuthorize, and @PostFilter via a single start import
* Also need import support for the enable annotations mentioned above.
* Added extra test case and sample (oauth2.groovy)
SpringApplicationLifecycle provides basic lifecycle operations on the
current Spring Boot application (that is checking if the application has
fully started and gracefully terminate the app). It can be registered as
an MBean of the platform MBean server if a specific property is set.
The Maven plugin uses that MBean to check that the application is ready
before ending the "start" phase. It uses it to trigger a proper shutdown
of the application during the "stop" phase.
If the process has to be forked, the platform MBean server is exposed on
a configurable port so that the maven plugin can connect to it.
Such change permits the maven plugin to integrate a classical integration
test scenario where the "start" goal is invoked during the
pre-integration phase and the "stop" goal during the post-integration
phase.
Closes gh-2525
Stephane Nicoll
Henri Kerola
Andy Wilkinson
Spring Buildmaster
Phillip Webb
Dave Syer
Johnny Lim
nagarajasr
Vedran Pavic
Jakub Narloch
Johannes Edmeier
mnhock
Kirill Vlasov
Matt Benson
Andrey Stolyarov
Eddú Meléndez
Greg Turnquist