Currently Spring Boot fails in Java 1.6 on Mac OS X due to the
"tools.jar" being integrated into classes.jar in the Apple version of
Java 6.
Apple fixed this with Java 7, but we should still support Java 6. We had
to roll back to maven-plugin-plugin 3.1 to make this work with Java 6
and 7.
All tests pass with Java 6 and Java 7.
Remove README files that have been since been migrated to the reference
documentation. Also updated remaining markdown files to asciidoctor to
save having a mix of different formats.
Fixed gh-503
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.
Trevor Menagh
Dave Syer
Phillip Webb
Oliver Gierke
Josh Long
kozazz
Chris Beams
Piotr Maj
Andy Wilkinson
Andy Piper
Sebastien Deleuze