This is quite a big step, but I think it helps a lot. Since Spring
Boot always creates an AuthenticationManager if it doesn't find one
already registered, it makes sense to also make it into a @Bean.
Spring Security does not register its AuthenticationManager by
default though, so we have to do that for it if the user has created
one with an @Autowired AuthenticationManagerBuilder, but not registered
it as a @Bean.
Having the @Bean (marked @Primary to prevent issues with @Autowired)
makes it easier to reason about what Spring Boot has done for you, and
easier to default in simple use cases to the boot-created
AuthenticationManager. For example, if I want an OAuth2 Authorization
Server with password grant, it makes total sense for the
AuthenticationManager for users to be the same as the @Primary one.
Now it is easy to set that up (just @Autowire it).
...bean with no explicit @Bean DispatcherServlet. We still have to check
by bean name (slightly unfortunate, but we need to avoid instantiating
too early) so there's now another magic
bean name for the registration bean ("dispatcherServletRegistration")
that the user has to replace if he wants the registration without
defining a servlet @Bean
Fixes gh-482
The source of the exception is in sun.misc (so hard to track down precisely)
but it's clear that the LaunchedJarURLClassLoader needs to be more
defensive and return null from findResource() if it can't find it.
Fixes gh-486
Makes them a lot more readable IMO, and also enables @Autowiring
from the context into the test case (sweeet). I added @DirtiesContext
to all of them as well to be on the safe side, but possbly that can be
optimized in some way as well.
Allowing use of embededded container in @SpringApplicationConfiguration
tests, e.g.
```
@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = Config.class)
@WebAppConfiguration
@IntegrationTest
public class SpringApplicationIntegrationTestTests {
@Test
public void nestedConfigClasses() {
String body = new RestTemplate().getForObject("http://localhost:8080/",
String.class);
assertEquals("Hello World", body);
}
@Configuration
@EnableWebMvc
@RestController
protected static class Config {
@Bean
public DispatcherServlet dispatcherServlet() {
return new DispatcherServlet();
}
@Bean
public EmbeddedServletContainerFactory embeddedServletContainer() {
return new TomcatEmbeddedServletContainerFactory();
}
@RequestMapping("/")
public String home() {
return "Hello World";
}
}
}
```
Fixes gh-473
We had been making a special case for logback.xml anyway, so
extending that to simply deleting recursively all of
src/main/resources (or equivalent) from target/classes (or
equivalent) seems like it's perfectly justifiable.
Fixes gh-451
The management.contextPath property should now be respected in a
secure application, whether or not the management.port is different.
Added some test cases in the sample to verify.
Fixes gh-469
Boot promotes the use of a templates directory for housing view
templates. Include this directory by default when building a jar file
from a CLI app.
Fixes#455
Explicitly link to install.txt in source repo to avoid issues on projects.spring.io with a broken relative link
... also fix this for rendered markdown on GH itself :-)
Use org.springframework.boot instead of ${project.groupId}
groupId in order to make it easier to use spring-boot-samples
modules as a starting point for new projects.
This turns out to affect JPA, but only because it looks for a URL for the
root of the classpath using ClassLoader.getResource("") which barfs in
an app launched from an executable JAR. It's easy to make a special case
for "" in the class loader, so I went ahead and did that. Possibly need
to think what the implication of getResources("") is as well (not
tested in an app yet).
Fixes gh-420
Profiles set with Environment.setActiveProfiles() (rather than
spring.profiles.active) *before* any config files are processed, are
treated as "additional" (to the ones supplied in spring.profiles.active
from all sources, files and System properties included).
Fixes gh-429