Tomcat 8 has different APIs again so it was quite difficult to
get it working and test it. The test is manual anyway (multi-module
project with JSPs in /META-INF/resources, not part of the samples),
and requires you to build a war and execute it (since the resource
paths are different when it's an archive).
Fixes gh-1131
Tweak 'fat jar' handling to generally improve performance:
- Allow JarURLConnection to throw a static FileNotFoundException when
loading classes. This exception is thrown many times when attempting
to load a class and is silently swallowed so there is no point in
providing the entry name.
- Expose JarFile.getJarEntryData(AsciiBytes) and store AsciiBytes in
the JarURLConnection. Previously AsciiBytes were created, discarded
then created again.
- Use EMPTY_JAR_URL for the JarURLConnection super constructor. The URL
is never actually used so we can improve performance by using a
constant.
- Extract JarEntryName for possible caching. The jar entry name
extracted from the URL is now contained in an inner JarEntryName
class. This could be cached if necessary (although currently it is
not because no perceivable performance benefit was observed)
Fixes gh-1119
Update JarFile to reuse the previously parsed entries when creating
filtered jars. This saves needing to re-scan the underlying file to
recreate a subset of entries.
See gh-1119
Drop JarEntryFilter arguments from the JarFile constructor and the
getNestedJarFile methods. Filtered JarFiles can still be obtained by
using the getFilteredJarFile() method.
This helps simplify the code a little and will make it easier to add
caching.
See gh-1119
In order to solve issues with multiple or incompatible AccessDecisionManagers, the CRaSH integration will now only delegate to an explicit shellAccessDecisionManager bean refs #1121
Adding an Order to the BeanPostProcessor and catching an exception
are enough to get a simple web app with @EnableGlobalMethodSecurity
and JDBC user details running. It actually doesn't solve an underlying
problem in Spring Security, but I'll deal with that separately.
See gh-1115
Update SolrAutoConfiguration to specifically require HttpSolrServer
and CloudSolrServer classes rather than the generic SolrServer.
This prevents the rather cryptic "@ConditionalOnMissingBean annotations
must specify at least one bean" error that can occur if an earlier
version of solr happens to be on the classpath (as is the case when
hibernate-search is used).
Fixes gh-1098
Refine auto-configuration for Spring Social to:
- Only auto-configure FB/Twitter/LinkedIn if the `app-id` property is
set.
- Only configure ConnectController and ProviderSignInController if
there is a ConnectionFactoryLocator.
- Auto-configure Spring Social's SpringSocialDialect for Thymeleaf if
Thymeleaf is present.
- Added several tests around Spring Social auto-configuration.
Fixes gh-1118
The default behaviour doesn't change with this commit, but now
the user has the option to specify a 'classifier' property
either in springBoot { classifier = 'exec' } (i.e. globally
for all repackage tasks) or in each repackage task, e.g.
bootRepackage { classifier = 'exec' }. In that case the original
archive is not overwritten but copied into <file>-<classifier>.jar
(or .war etc.) and then enhanced.
Fixes gh-1113, fixes gh-141 also I believe.
It needs to run as soon as the DataSource is available really otherwise
anything else that depends on the DataSource (like Security JDBC
initializers) might fail when it tries to use it.
One change from 1.1.1 is that if you have a schema.sql you had better
make sure your data.sql talks to the same tables. In 1.1.1 you could
sometimes get away with letting Hibernate initialize the tables for
your data.sql and *also* have a schema.sql. This was fragile and doomed
to fail eventually if the DataSourceInitializer somehow got
initialized earlier (e.g. through a @DependsOn), so in the spririt
of honesty being the best policy we explicitly disallow it now.
Fixes gh-1115
The class Compile was deprecated and will be removed in Gradle 2.0 (it is
already removed in the release canidate).
Instead we should use JavaCompile. Fixes gh-1066.
Prior to this commit it was not safe to start several contexts
using the HornetQAutoConfiguration in the same VM. Each context
was trying to start their own HornetQ embedded broker by default but
only the first was really starting. Worse, the various InVM connection
factories were all silently connecting to the first broker.
This commit introduces a new "serverId" property that is an auto-
incremented integer by default. This identifies the server to connect
to and allows each context to start its own embedded broker in total
isolation of other contexts.
This commits makes it possible for a context to disable its own
embedded broker and connect to an existing one, potentially started
by another context.
Fixes gh-1063
This commit reuses the standard behavior provided by Properties for
parsing keys rather than parsing the keys ourselves. This provides a
consistent features set regardless of where the property is defined.
Fixes gh-1110
Prior to this commit, some tests were creating a parent/child
relationship but were only closing the child context. This could
be an issue with the autoconfig module as a lot of auto-config
kicks in by default.
This commit adds a new test utility designed to properly handle
those situations. Updated tests that were creating a context
hierarchy to benefit from that.
Fixes gh-1034
Dave Syer
Phillip Webb
Tadaya Tsuyukubo
Phillip Wirth
Christian Dupuis
Tobias Gesellchen
Stephane Nicoll