- 23 4月, 2013 3 次提交
-
-
由 Juergen Hoeller 提交于
Use LinkedHashMaps/Sets wherever exposed to users, and code tests defensively in terms of expected Map/Set ordering. Otherwise, there'll be runtime order differences between JDK 7 and JDK 8 due to internal HashMap/Set implementation differences. Issue: SPR-9639
-
由 Juergen Hoeller 提交于
Issue: SPR-9641
-
由 Juergen Hoeller 提交于
In particular, avoid accidental usage of ASM for core JDK types - which will fail in case of a new bytecode version in the JDK, even if the application itself has been compiled with an earlier bytecode target. Issue: SPR-10292
-
- 14 4月, 2013 3 次提交
-
-
由 Phillip Webb 提交于
# By Stevo Slavic * SPR-10438: Fix JasperReport tests to ignore missing fonts
-
由 Stevo Slavic 提交于
Add 'jasperreports.properties' to ignore missing fonts in order that tests pass on Linux. The upgraded JasperReports 5.0.4 throws a JRFontNotFoundException when a report font is not found. This caused Spring MVC tests to fail since the example reports used the 'Arial' font which is not shipped with most Linux distributions. An alternative fix would have been to package fonts with the reports using JasperReports font extension support. Issue: SPR-10438
-
由 Phillip Webb 提交于
* 3.2.x: Update javadoc external links JdbcTemplate etc Removed unnecessary default value of LifecycleGroup.lifecycleBeans Introduced public ArgumentPreparedStatementSetter and ArgumentTypePreparedStatementSetter classes Defensively uses JDBC 3.0 getParameterType call for Oracle driver compatibility Preparations for 3.2.3 Fixed ReflectiveMethodResolver to avoid potential UnsupportedOperationException on sort Fixed Jaxb2Marshaller's partial unmarshalling feature to consistently apply to all sources Update copyright year in reference documentation Conflicts: build.gradle gradle.properties spring-context/src/main/java/org/springframework/context/support/DefaultLifecycleProcessor.java spring-jdbc/src/main/java/org/springframework/jdbc/core/ArgumentPreparedStatementSetter.java spring-jdbc/src/main/java/org/springframework/jdbc/core/ArgumentTypePreparedStatementSetter.java
-
- 12 4月, 2013 1 次提交
-
-
由 Sam Brannen 提交于
-
- 30 3月, 2013 6 次提交
-
-
由 Phillip Webb 提交于
Fix broken external javadoc links for URLs that have been recently moved.
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
EclipseLinkJpaDialect uses JPA 2.0's EntityManager unwrap method now for retrieving the underlying UnitOfWork/Connection
-
由 Juergen Hoeller 提交于
HibernateJpaDialect's HibernateConnectionHandle does not call close() for Hibernate 4.x anymore, since on 4.2, the exposed Connection handle isn't a "borrowed connection" wrapper but rather the actual underlying Connection - with a close() call immediately returning the Connection to the pool and making the local handle invalid for further use within the transaction. Also using JPA 2.0's EntityManager unwrap method now for retrieving the underlying Hibernate Session. Issue: SPR-10395
-
由 Juergen Hoeller 提交于
-
由 Phillip Webb 提交于
Fix broken external javadoc links for URLs that have been recently moved.
-
- 29 3月, 2013 12 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
Upgraded to JasperReports 5.0 (preserving compatibility with all previous releases) and POI 3.9 (preserving compatibility with POI 3.5+)
-
由 Juergen Hoeller 提交于
Removed deprecated JpaTemplate and JpaInterceptor classes; dropped unused EntityManager(Factory)Plus mechanism
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
Upgraded JdkVersion and CollectionFactory to JDK 1.6+, also removing deprecated methods from CollectionFactory
-
由 Juergen Hoeller 提交于
Driven by the need for implementing Bean Validation 1.1's "releaseInstance" method in SpringConstraintValidatorFactory, as a direct counterpart to the use of AutowireCapableBeanFactory's "createBean(Class)" in "getInstance". Issue: SPR-8199
-
由 Juergen Hoeller 提交于
Use JDK 1.6's Collections.newSetFromMap instead of manually accessing Maps with dummy Boolean values
-
由 Juergen Hoeller 提交于
Consistently refer to most recent version of javax.el, in order to be compatible with Hibernate Validator 5.0 when doing integration tests Issue: SPR-8199
-
由 Juergen Hoeller 提交于
MethodValidationInterceptor autodetects Bean Validation 1.1's ExecutableValidator API now and uses it in favor of Hibernate Validator 4.2's native variant. SpringConstraintValidatorFactory implements Bean Validation 1.1 "releaseInstance" method against new "destroyBean(Object)" method in AutowireCapableBeanFactory. LocalValidatorFactoryBean adapts Spring-provided ParameterNameDiscoverer onto Bean Validation 1.1's ParameterNameProvider mechanism. LocalValidatorFactoryBean reflectively adapts between the different ResourceBundleLocator SPI location in Hibernate Validator 4.2 versus 5.0. LocalValidatorFactoryBean implements Bean Validation 1.1 "close" method. Note: We still compile against Bean Validation 1.0 in order to not have to implement "forExecutables()" and "getParameterNameDiscoverer()" in LocalValidatorFactoryBean, SpringValidatorAdapter and CustomValidatorBean. Implementing those methods would imply references to Bean Validation 1.1 interfaces that break runtime compatibility with Bean Validation 1.0. Unfortunately, this means that all Bean Validation 1.1 API access has to be done via reflection. Issue: SPR-8199
-
由 Juergen Hoeller 提交于
Driven by the need for implementing Bean Validation 1.1's "releaseInstance" method in SpringConstraintValidatorFactory, as a direct counterpart to the use of AutowireCapableBeanFactory's "createBean(Class)" in "getInstance". Issue: SPR-8199
-
- 28 3月, 2013 3 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-8194
-
由 Juergen Hoeller 提交于
JSR-236 support, in particular adapting to JSR-236 Triggers and exposing additional metadata through ManagedTasks This is built into ConcurrentTaskExecutor and ConcurrentTaskScheduler now, automatically detecting the JSR-236 ExecutorService variants and adapting to them. Issue: SPR-8195
-
由 Juergen Hoeller 提交于
Issue: SPR-9139
-
- 27 3月, 2013 2 次提交
-
-
由 Juergen Hoeller 提交于
In the course of this effort, our joinTransaction() support has been overhauled to work for shared EntityManagers as well, since an unsynchronized shared EntityManager will nevertheless be scoped for the current transaction but not automatically join it (as per the JPA 2.1 spec). In the JTA case, we'll simply create an unsynchronized target EntityManager and will upgrade it to a synchronized one (later in the same transaction, if necessary) through an implicit joinTransaction() call. In the JpaTransactionManager case, we'll unbind the primary target EntityManager and will expose an unsynchronized EntityManager instead, upgrading it the same way as with JTA, with the primary EntityManager in that case just serving as a vehicle for transaction begin/commit/rollback calls. For extended EntityManagers, we've just added further combinations to the existing variants: application-managed EntityManagers which may nevertheless auto-join transactions (EntityManagerFactory.createEntityManager with SynchronizationType.SYNCHRONIZED), and container-managed EntityManagers which might opt for not auto-joining transactions (@PersistenceContext with synchronizationType=UNSYNCHRONIZED). Issue: SPR-8194
-
由 Juergen Hoeller 提交于
First pass completed, with support for the standard JMS 2.0 API in our CachingConnectionFactory and support for a delivery delay setting in JmsTemplate. Note that none of this has been tested against an actual JMS 2.0 provider yet, due to no such provider being available yet. Known limitations: * Spring's SingleConnectionFactory and CachingConnectionFactory do not support createContext calls for JMSContext creation at this point. Note that the JMSContext model bypasses the point of a Connection/Session pool anyway; this will only really work with a native JMS 2.0 ConnectionFactory and provider-specific pooling such as in an EE environment. * JmsTemplate has no out-of-the-box support for send calls with an async completion listener. Note that a CompletionListener can be specified in a custom ProducerCallback implementation if really necessary. There is no special support for the simplified JMSContext API, and likely never will be: JMSContext can be used from a native ConnectionFactory directly. @Inject JMSContext isn't supported due to rather involved rules for defining and scoping the injected context which are quite at odds with the Spring way of doing these things. We strongly recommend JmsTemplate instead, or @resource ConnectionFactory with a createContext call within a Java 7 try-with-resources clause (as shown in the specification). After all, JMSContext has primarily been designed with EE's one-session-per-connection model and JTA transactions in mind, not with Spring-style use of a native JMS provider and native JMS transactions. Issue: SPR-8197
-
- 26 3月, 2013 1 次提交
-
-
由 Sam Brannen 提交于
This commit removes the suppression of warnings in Servlet and Portlet mocks since such suppression is no longer necessary with the upgrade to version 3.0 of the Servlet specification.
-
- 21 3月, 2013 3 次提交
-
-
由 Juergen Hoeller 提交于
Assigned cache manager name in order to avoid EhCache assertion failure in case of multiple tests executed on the same VM
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
Upgraded all Servlet API mocks to Servlet 3.0 (with a little bit of Servlet 3.1 support in MockHttpServletResponse)
-
- 20 3月, 2013 6 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
Revised WebServiceFeature handling: requiring JAX-WS 2.1+, including support for JAX-WS 2.2 service-level features now
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-