Tomcat in particular sets an environment variable in it's shell scripts
that people commonly use to start the container. So if people deploy a war
file to a stock Tomcat server they can't override the logging config, even
with the default location. With this change at least that should work
(for logback and log4j anyway). Tested with logback.
See gh-1432
Users could be surpised if they register a Filter with an @Order and it
isn't apparently respected. This change accumulates all Filters and
FilterRegistrations (for instance) before sorting them.
Fixes gh-1455
Update auto-configuration for JMS and JTA to support a ConnectionFactory
and TransactionManager exposed via JNDI.
JTA configuration now attempts a simple JtaTransactionManager before
attempting Bitronix or Atomikos configuration.
The JMS auto-configuration also now attempts to find a ConnectionFactory
from JNDI before falling back to the previous strategies. If JNDI is
present a JndiDestinationResolver is also configured instead of the
default DestinationResolver.
See gh-947
Add support classes for the Bitronix JTA library, including:
- A Spring friendly ConnectionFactoryBean and DataSourceBean with
support for setting a direct XA source.
- A PostProcessor to apply shutdown ordering automatically.
See gh-947
Add support classes for the Atomikos JTA library, including:
- A Spring friendly ConnectionFactoryBean and DataSourceBean.
- A PostProcessor to apply "depends-on" ordering automatically.
- A bindable properties class for type-safe configuration.
See gh-947
Automatically apply @EnableJMS when spring-jms is on the classpath
and the annotation hasn't already been applied. This allow for Spring's
new @JmsListener annotation to just work.
Fixes gh-1425
Add `spring.datasource.jndi-name` property to allow a DataSource to be
looked up from JNDI as an alternative to defining a URL connection.
Fixes gh-989
Velocity and Freemarker share some common properties so the base class for
configuring their properties makes some sense. Unfortunately the implementation
pulls in Spring MVC at runtime because of the signature of one method (that
would never be called). We can fix that in a number of ways, but the least
disruptive is probably to change the signature of that method and only refer
to the concrete template view resolver type if the method is called.
Fixes gh-1437
For some reason I thought that the DispatcherServlet default handler
would log all exceptions, so if we did it in the ErrorPageFilter it
would lead to duplicates. That appears not to be the case.
Fixes gh-1427
Dave Syer
Phillip Webb
David Liu
Andy Wilkinson
Josh Long