Since groovy-templates is included with groovy-all it is unreasonable
to expect anyone who has it on their classpath to have resolvable templates.
We may need to revisit this decision, but since the origain feature
that drove this was thymeleaf and idaiotic users having it on their
classpath but not using it, maybe we don't need to.
Default suffix .tpl. If groovy-templates is on the classpath user
can now add templates and get them rendered and resolved in an MVC
app.
TODO: Macro helpers for message rendering etc.
See gh-878
- Add createConnectionFactory method on ActiveMQProperties
- Change getBrokerUrl to return the broker URL and add new deduce method
- Move static methods to end of class
- Apply source formatting
Update all @PostConstruct methods to ensure that they don't throw
checked exceptions. Required to allow deployment of Spring Boot
applications on Glassfish.
Fixes gh-868
Since ActiveMQ 5.8.0, the modules structure has been revisited and
activemq-core no longer exists. The activemq-broker is required to
create an embedded broker. Since Boot creates such broker by default
if ConnectionFactory is present, a condition has been added to do so
only when the necessary classes are present in the classpath.
The default embedded broker is now configured to disable message
persistence altogether as this requires an extra jar since 5.8.0, i.e.
activemq-kahadb-store.
Split the ActiveMQ auto configuration from the JmsTemplate auto
configuration so these are totally independent.
ActiveMQAutoConfiguration has been created to detect and configure
the ActiveMQ broker if necessary.
The brokerUrl parameter was ignored as long as the inMemory parameter
was true. The actual brokerUrl to use is now determined by the user
defined values of those parameters: if the brokerUrl is set, it is always
used. If no brokerUrl is set, the value of inMemory determines if an
embedded broker should be used (true) or a tcp connection to an
existing local broker (false).
JmsTemplateAutoConfiguration now creates a JmsTemplate only if a
ConnectionFactory is available.
Fixes gh-872, gh-882, gh-883
If an execution of the repackage goal is present in a project with
'pom' packaging, it is now skipped. This allows to configure the
plugin in the parent.
Fixes gh-867
Adds JpaProperties to bind to spring.jpa.* (making those
properties easier to reason about and visible in the
/configprops endpoint).
Also allows easy configuration of multiple EntityManagerFactories via new
EntityManagerFactoryBuilder. JpaBaseConfiguration has a @Bean of that type
so users can inject it to create new or additional EntityManagerFactories.
This also simplifies the Hibernate autoconfiguration.
Also renames the DataSourceFactory to DataSourceBuilder (since that's what it
is).
The configuration within an execution is only applied when that
particular execution is invoked as part of the build. It is not
applied when the plugin is invoked on the command line (i.e.
mvn spring-boot:run).
This commit clarifies the situation so that users can safely copy/paste
those bits and get the expected behavior.
Fixes gh-875
The maven plugin now forks a new process when it starts a boot app. This
makes remote debugging of the app impossible without the ability to pass
extra JVM arguments.
This commit adds a "jvmArguments" attribute to the RunMojo that defines
additional JVM arguments to set on the forked process.
Fixes gh-848
We now have a much simpler DataSourceAutoConfiguration that binds to whatever
DataSource concrete type it finds at runtime. To be able to quickly switch between
Hikari and the other types of DataSource there's a minute shim for translating
the common properties (username, password, url, driverClassName), but actually
only url is different. The shim and also DataSource initialization is supported
through DataSourceProperties, but the other native properties get bound directly
through the concrete runtime type of the DataSource.
The /configprops endpoint works (and is exposed in the actuator sample).
Fixes gh-840, fixes gh-477, see also gh-808.
Introspects the properties that are being exposed in the report
and only renders the ones that are a) convertible from String
and b) have a setter. That goes a long way to making it a bullet
proof generic renderer of any Java object that can be bound with
@ConfigurationProperties.
This allows multiple beans of the same type to be bound with
different prefixes. As a side effect you get default binding
if the bean class is itself @ConfigurationProperties.
Update the BasicErrorController so that it no longer needs to implement
@ControllerAdvice or have an @ExceptionHandler method.
A new ErrorAttributes interface is now used to obtain error details,
the DefaultErrorAttributes implementation uses a
HandlerExceptionResolver to obtain root exception details if the
`javax.servlet.error.*` attributes are missing.
This change also removes the need for the extract(...) method on
ErrorController as classes such as WebRequestTraceFilter can
now use the ErrorAttributes interface directly.
See gh-839, gh-538
Fixes gh-843
