This commit polihes the original Neo4j contribution in several areas.
Rather than providing the packages to scan, this commit rearranges the
`EntityScan` and `EntityScanRegistrar` so that the logic can be shared
for other components. If no package is provided, scanning now defaults to
the "auto-configured" package(s) and a `@NodeEntityScan` annotation
allows to override that.
The configuration has also been updated to detect the driver based on the
`uri` property. If the embedded driver is available we use that by
default. If it is not available, we're trying to connect to a Neo4j
server running on localhost. It is possible to disable the embedded mode
or set the `uri` parameter explicitly to deviate from these defaults.
The sample no longer relies on the embedded driver for licensing reason:
rather it expects an instance running on localhost (like other
data-related samples) and gracefully ignore any connection error. A
README has been added in the sample to further explain the available
options;
Closes gh-5458
Update the samples and integration tests to use Java 8. There's no
specific reason to keep them on Java 6 and it helps keep Eclipse happy
if we upgrade.
If spring-hateoas is on the classpath and an MvcEndpoint returns a
@ResponseBody it will be extended and wrapped into a Resource with links.
All the existing endpoints that return sensible JSON data can be extended
this way (i.e. not /logfile). The HAL browser will also be added as an
endpoint if available on the classpath. Finally, asciidocs for the
Actuator endpoints are available as a separate jar file, which if
included in an app will also generate a new (HTTP) endpoint.
Fixes gh-1390
This commit adds support for automatically configuring Spring Session.
In a web application when both Spring Session and Spring Data Redis
are on the classpath, Spring Session's Redis Http Session support
will be auto-configured. The max inactive interval for Redis-backed
sessions can be configured via the environment using the existing
server.session-timeout property.
Closes gh-2318
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)
This avoids a potential problems with ordering between Dropwizard and
normal repository configuration. A Dropwizard sample has been added to
verify the behaviour.
Spring Buildmaster
Phillip Webb
Gytis Trikleris
Stephane Nicoll
Eddú Meléndez
Dave Syer
Julien Dubois
Lucas Saldanha
Ivan Sopov
Andy Wilkinson
Greg Turnquist