Restore previous behavior where JarFile URLs are always prefixed with
"jar:". I believe that the prefix is required in order to remain
compatible with standard JAR URLs.
This reverts commit 825fc2f7df.
The existing behaviour of JobLauncherCommandLineRunner was really too
basic. It has now been enhanced (at the expense of duplicating a lot
of code in Spring Batch it seems) to automatically increment job
parameters if it can, and to retry a failed or stopped execution
if it can (without incrementing, but with additional job parameters
added from command line if they are non-identifying).
The JobLauncherCommandLineRunner is more extendable and exposes
its DI wiring points now as well, so hopefully users can make
use of it independently of autoconfig (by providing a @Bean of
that type).
Not everything from the wishlist in gh-325 is implememented yet,
but it should be a good platform to work with and to extend.
The default executor for publishing metrics was a single
thread (native JDK) ExecutorService with a non-daemon thread.
Changed it to a Spring-managed thread pool of size 1, which
is then shutdown with e ApplicationContext automatically.
Fixes gh-388
Better even than logging would be to fail fast? Surely it's a
mistake not to have any /templates if Thymeleaf is in use.
User can disable failfast by exlcuding thymeleaf configuration
or by providing their own ITemplateResolver.
Fixes gh-294
User can switch the behaviour on and off with
spring.datasource.continueOnError:true|false. I decided
not to add an extra nested level of property resolution
because of the existing spring.datasource.schema
(and other properties relating to initialization) because
concision seemed like a good thing with those more common
settings.
Fixes gh-374
Added basic-* log configuration files that are loaded in the
beforeInitialization() phase. They don't contain any file
logger so no empty spring.log is ever created.
Fixes gh-303
Jetty apparently does it differently (different version of
Jasper maybe), so you need a unique jarFileURL for each
nested JAR (previously they were all set to the parent
archive URL).
Also added the root of the main archive as a valid
document root.
For gh-367
The DispatcherServletAutoConfiguration had a condition on it that
meant it wasn't used at all if there was no EmbeddedServletContainerFactory.
It's amazing that any WAR ever deployed.
Also added some info logging to servlet and filter registrations.
Restore the order that `ConfigFileApplicationListener` attempts to load
application.properties so that local files always have a higher
precedence than bundled classpath files.
This fixes a regression introduced with 1.0.0.RC2.
Fixes gh-370
Requires Loaded 1.1.5 (or better).
For Maven you can just add springloaded to the dependencies of the
spring-boot plugin (and also set MAVEN_OPTS=-noverify).
For Gradle add springloaded to the build dependencies (-noverify
can be added by the plugin).
In both cases there is also support for adding an arbitrary java agent
via configuration. Samples are provided in
spring-boot-sample-[simple,web-ui].
The ApplicationPlugin is only added if there is no JavaExec task
already present, and additionally it computes its own man class if
none is provided. So "gradle run" and "gradle bootRun" look
superficially similar, but "bootRun" has extra options, including
the agent and Loaded support.
Fixes gh-251, gh-183
Update OnBeanCondition to attempt to consider FactoryBean classes
for bean type matches. To ensure early instantiation does not occur, the
object type from the FactoryBean is deduced by resolving generics on the
declaration.
Fixes gh-355
Here's what I think works best:
* Any profile in the Environment before application.yml
is processed takes precedence (i.e. it will be last in the
list of active profiles in the live app)
* Any profile in the Environment before SpringApplication
starts takes precedence (so any added on the command line or
with System properties come after ones added using
the SpringApplication API)
* The order of profiles in application.yml is irrelevant -
profiles are applied in the order they come out of
Environment.getActiveProfiles()
Fixes gh-342
Ordering: profiles are applied in order (from the active profiles
list in the Environment), with the last one winning as far as
property values goes. This *does* mean that a profile activated
inside application.yml is applied last and hence takes precedence.
It's debatable whether that is the right semantics, but that's
what it is for now.
Re gh-342: a profile added via SpringApplication also takes
precedence over one added on the command line. Also debatable
but at least it's predictable.
Naming: a profile adds "#<profile>" to the end of a property source
name (no more, no less)
Phillip Webb
Oliver Gierke
Dave Syer
hoserdude
joschs
Christian Dupuis
Jakub Kubrynski
Andy Wilkinson