If set *and* there is a transaction manager in the context, then the
listener container created by Spring Boot will use the transaction
manager to execute the listeners.
Fixes gh-3432 (by virtue of not requiring a JtaTransactionManager any
more).
When Spring Security sends 302 responses to a login page we don't get
any information about the request matching in Spring MVC. Consequently
apps can end up with a lot of counter.status.302.* metrics (where
"*" can be whatever the user sent).
This change treats 3xx the same as 4xx (if it is unmapped it just gets
added to a metric called "unmapped" instead of using the actual request
path).
Fixes gh-2563
When writing a jar, once an entry has been written it will never be
overwritten, i.e. the first write of a given entry will win. Previously,
when repackaging a jar, the existing contents were written followed by
any libraries. This caused a problem when repackaged a WAR file and
a library needed to be unpacked as the existing entry in WEB-INF/lib
would prevent the library with the UNPACK comment from being written.
This was addressed in f761916b by inverting the order so libraries
would take precedence over entries in the source jar.
It’s now become apparent that this change in the order causes a problem
for users who are obfuscating their code. The obfuscated code exists in
the source jar but is also provided to the repackager in its original
form as a library. When libraries take precedence, this means that the
code in its original form ends up in the repackaged war and the
obfuscation is lost.
This commit updates the repackager to write libraries that require
unpacking first. This allows the UNPACK comment to be written even if
there’s also a source entry for the library. Next, source entries are
written. This allows obfuscated source entries to take precedence over
any unobfuscated library equivalents. Lastly, standard libraries that
do not require unpacking are written into the repackaged archive.
Closes gh-3444
Ensure that FlywayAutoConfiguration and LiquibaseAutoConfiguration occur
after HibernateJpaAutoConfiguration so that the DependsOnPostProcessor
condition can correctly check for a LocalContainerEntityManagerFactory
bean.
Fixes gh-3437
The order of property values is only preserved if we check carefully
that each property is actually present in the source being inspected.
Fixes gh-3385
Update RelaxedDataBinder to so that property ordering is respected even
if relaxed names are used. Prior to this commit a System property named
`FOO_BAR` would never get bound to a `fooBar` field if `foo-bar` was
defined in application.properties.
Fixes gh-3385
If a JtaTransactionManager is present, it is associated with the
auto-created JmsListenerContainerFactory. However, if no such transaction
manager is present, local transaction support is not enabled.
This gives a default situation where the message is acknowledged even
before the listener is invoked. We now make sure to turn on local JMS
transactions if no JtaTransactionManager is present.
Fixes gh-3393
Previously, JacksonHttpMessageConvertersConfiguration would configure a
general-purpose MappingJackson2HttpMessageConverter only if there was
no existing MappingJackson2HttpMessageConverter in the application
context. This was problematic when a
TypeConstrainedMappingJackson2HttpMessageConverter bean was present.
Such a bean is only capable of performing conversion for a specific
type, and therefore is no substitute for a general purpose converter,
yet its presence was causing the auto-configuration of a general
purpose converters to be turned off. This would leave Spring MVC’s
default converter being used for application/json requests which would
not honour the user’s Jackson configuration.
This commit enhances @ConditionalOnMissingBean so that the annotation
can be used to specify one or more types that should be ignored when
searching for beans. This allows the
TypeConstrainedMappingJackson2HttpMessageConverter beans that are
published by Spring Data REST to be ignored such that the
general-purpose MappingJackson2HttpMessageConverter is still
auto-configured.
Fixes gh-2914
Update MustacheViewResolver so that buildView() is called to create
the MustacheView. This sets fields such as `contentType` and allows us
to remove explicit setApplicationContext() and setServletContext()
calls.
Fixes gh-3265
GzipFilterProperties uses HttpMethod so GzipFilterAutoConfiguration,
which uses GzipFilterProperties, needs to be conditional on HttpMethod
being on the classpath.
Closes gh-3362
If java.io.tmpdir is configured to a directory that does not exist,
calls to File.createTempFile will fail with an IOException with the
message "The system cannot find the path specified". Unfortunately,
the path the was specified is not included in the message.
Rather than trying to automatically create the directory in what may
be a misconfigured location, we now include the value of
java.io.tmpdir in our own exception's message. Hopefully this will
help users to figure out what they've done wrong.
Closes gh-3307
Previously, when an exception was thrown by a Controller in an
application deployed to a servlet container the exception that was
handled would be Spring Framework’s NestedServletException rather than
the exception thrown by the application. Furthermore, when an exception
was thrown or the response was used to send an error, the
javax.servlet.error.request_uri request attribute would not be set. This
differed from the behaviour in an executable jar/war where the exception
would be the one thrown by the application, and the request_uri
attribute would be set.
This commit updates ErrorPageFilter, which is only involved in a servlet
container, to unwrap a NestedServletException so that it’s the
application’s exception that’s handled, and to set the request_uri
attribute in the event of an exception being thrown or an error being
sent.
Closes gh-3249
Previously, an address that ended in a "/" would result in the virtual
host being an empty string. This was inconsistent with setVirtualHost
which would map an empty string to "/".
This commit updates the address parsing logic to call setVirtualHost
rather than assigning the value directly to this.virtualHost. This
ensures that the special handling for an empty string is applied
consistently.
Closes gh-3304
By default, SpringApplication attempts to deduce the application class
by looking for a main method in the stack. This does not work when
the application is launched by a servlet container via
SpringBootServletInitializer as there's either no main method in the
stack, or the main method is that of the servlet container, rather
than the application.
This commit updates SpringBootServletInitializer to configure the
main class of the SpringApplication that it creates to be the
application's SpringBootServletInitializer subclass. This is done
prior to calling configure, so the main class can still be specified
by the application if required.
Closes gh-3061
Update WarPackagingTests to ignore any IOExceptions when closing
created war files. Exceptions were sometimes thrown when running on a
Linux NTFS mount.
Fixes gh-3255
Previously, DefaultRepositorySystemSessionAutoConfiguration would
read the local repository configuration from settings.xml, but did
not perform any property interpolation. This would leave placeholders
such as ${user.home} as-is and result in the use of the wrong
location. To address this, the code that reads settings.xml has been
updated to provide the current System properties as a property
interpolation source.
RepositoryConfigurationFactory configures the local repository as a
"remote" repository when the local repository location has been
overridden. This allows spring grab to copy dependencies from the
local repository into the grab output location (configured via the
grape.root system property) rather than having to download them again.
This logic did not consider the customization of the local repository
location via settings.xml so the dependencies would be downloaded again.
To address this, RepositoryConfigurationFactory has been updated to
attempt to use the location configured in settings.xml, before falling
back to the default location.
The logic that reads settings.xml has deliberately been duplicated. It
could have been extracted into a separate class, but this is only a
temporary measure until gh-3275 is tackled. Duplication was deemed
preferable to adding a new public class in 1.2.x that we’d then want to
remove in 1.3.
Closes gh-3274
