- 15 10月, 2013 13 次提交
-
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
- Now avoiding NullPointerExceptions in GenericTypeResolver's resolveReturnTypeForGenericMethod() in case the supplied ClassLoader is null. - AutowireUtils.resolveReturnTypeForFactoryMethod() now properly asserts that the supplied ClassLoader is not null. - Fixed copy-n-paste errors in Javadoc for AutowireUtils.resolveReturnTypeForFactoryMethod(). Issue: SPR-10411
-
由 Sam Brannen 提交于
SPR-10411
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
This change adds an alternative UUID generation strategy to use by default in MessageHeaders. Instead of using SecureRandom for each new UUID, SecureRandom is used only for the initial seed to be provided java.util.Random. Thereafter the same Random instance is used instead. This provides improved performance while id's are still random but less securely so.
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10890
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10955
-
由 Rossen Stoyanchev 提交于
Before this change, async result handling on controller methods failed to observe type-level annotations annotations. The issue was never noticed until we started supporting type-level @ResponseBody and the @RestController meta annotation. Issue: SPR-10905
-
由 Juergen Hoeller 提交于
Includes revisions of MethodParameter and DependencyDescriptor (in particular towards a reference to the containing class). Also refines several ResolvableType method signatures. Issue: SPR-9965
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
We're consistently resolving class names now, and the entire algorithm moved from GenericTypeResolver to the internal AutowireUtils helper in the bean factory package. Issue: SPR-10411
-
由 Juergen Hoeller 提交于
Issue: SPR-10185
-
由 Juergen Hoeller 提交于
Issue: SPR-10974
-
- 14 10月, 2013 2 次提交
-
-
由 Sam Brannen 提交于
-
由 Brian Clozel 提交于
Prior to this commit, the template method createDataBinderFactory would only allow ServletRequestDataBinderFactory as a return type. This commit updates the method signature and allows InitBinderDataBinderFactory, a superclass of the previous one. Then other implementations can override this method and return other InitBinderDataBinderFactory types. Issue: SPR-10920
-
- 13 10月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
This change adds support for @Header and @Headers annotated method arguments to spring-messaging. Also supported are arguments of type MessageHeaders, and MessageHeaderAccessor (including sub-types of MessageHeaderAccessort as long as they provide a wrap(Message<?>) static factory method). This change also renames @MessageBody to @Payload. Issue: SPR-10985
-
- 12 10月, 2013 5 次提交
-
-
由 Phillip Webb 提交于
Fix HttpInvokerClientInterceptor.convertHttpInvokerAccessException to return the translated exception rather than throwing it. This brings the method implementation in line with the Java Doc and the obvious original intent. Issue: SPR-10965
-
由 Phillip Webb 提交于
* SPR-10501: Add Reference to Spring AMQP Remoting in docs
-
由 Gary Russell 提交于
Beginning with 1.2.0, Spring AMQP now supports remoting over AMQP with a proxy factory bean an invoker service exporter. Add documentation to the Spring Framework remoting section with a link to the Spring AMQP documentation. Issue: SPR-10501
-
由 Phillip Webb 提交于
* fix-doc-cache: Fix Cache documentation
-
由 Grzegorz Rożniecki 提交于
Fixed malformed code snippets, formatted whitespace and changed invalid external link.
-
- 11 10月, 2013 3 次提交
-
-
由 Rossen Stoyanchev 提交于
The MessageConverter interface in spring-messaging is now explicitly designed to support conversion of the payload of a Message<?> to and from serialized form based on MIME type message header. By default, the MessageHeaders.CONTENT_HEADER header is used but a custom ContentTypeResolver can be configured to customize that. Currently available are Jackson 2, String, and byte array converters. A CompositeMessageConverter can be used to configure several message converters in various places such as a messaging template.
-
由 Phillip Webb 提交于
Issue: SPR-10973
-
由 Phillip Webb 提交于
Fix ResolvableType.isAssignableFrom to correctly deal with <?> style generics. Issue: SPR-10973
-
- 10 10月, 2013 4 次提交
-
-
由 Phillip Webb 提交于
Refactor AbstractMessageConverterMethodArgumentResolver and BridgeMethodResolver to use ResolvableType in preference to deprecated GenericTypeResolver calls. Issue: SPR-10980
-
由 Phillip Webb 提交于
Refactor GenericCollectionTypeResolver to make use of ResolvableType for generic resolution. Issue: SPR-10977
-
由 Phillip Webb 提交于
Refactor GenericTypeResolver to make use of ResolvableType for generic resolution. Issue: SPR-10978
-
由 Phillip Webb 提交于
Add a new ResolvableType Class which encapsulates java.lang.reflect.Type, providing access to supertypes, interfaces and generic parameters along with the ability to ultimately resolve to a java.lang.Class. ResolvableTypes may be obtained from fields, method parameters, method returns, classes or directly from a java.lang.reflect.Type. Most methods will themselves return ResolvableTypes, allowing easy navigation. For example: private HashMap<Integer, List<String>> myMap; public void example() { ResolvableType t = ResolvableType.forField( getClass().getDeclaredField("myMap")); t.getSuperType(); // AbstractMap<Integer, List<String>>; t.asMap(); // Map<Integer, List<String>> t.getGeneric(0).resolve(); // Integer t.getGeneric(1).resolve(); // List t.getGeneric(1); // List<String> t.resolveGeneric(1, 0); // String } Issue: SPR-10973
-
- 09 10月, 2013 2 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10789
-
- 08 10月, 2013 8 次提交
-
-
由 Brian Clozel 提交于
Prior to this commit, one could only match exact URLs in redirectedUrl and forwardedUrl ResultMatchers. When creating a resource with a REST service, URLs often contain the id the new resource, like "/resource/12". This commit updates those ResultMatchers to support both exact matches and AntPath matches, using new methods. The former URL then can be tested against "/resource/*" in MVC tests. Issue: SPR-10789
-
由 Rossen Stoyanchev 提交于
This change reverts recent commits made to expand the resource handling mechanism in Spring MVC. The changes will move into a separate branch and likely into a separate project allowing it to mature and evolve without being tied to the main framework release schedule. Issue: SPR-10933, SPR-10310
-
由 Rossen Stoyanchev 提交于
This reverts commit d4a0e628, reversing changes made to 8abe9497.
-
由 Rossen Stoyanchev 提交于
This reverts commit 1ba806b1.
-
由 Rossen Stoyanchev 提交于
This reverts commit f8e1f06d.
-
由 Rossen Stoyanchev 提交于
This reverts commit c01f45fa.
-
由 Brian Clozel 提交于
Prior to this commit, one could not test for the absence of a specific HTTP header in a response. Using header("X-Custom-Header", Matchers.nullValue()) would not work because it tests for an empty value of an existing header. This commit adds a doesNotExist method on the HeaderResultMatcher. Issue: SPR-10771
-
由 Brian Clozel 提交于
Prior to this commit, one could call the setStatus method on this Mock object and update the response's status, even though the sendError method had already been called. According to the HttpServletResponse Javadoc, sendError() methods commit the response; so the response can't be written after that. This commit fixes MockHttpServletResponse's behavior; setStatus methods do not update the status once the response has been committed. Issue: SPR-10414
-
- 07 10月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-
- 05 10月, 2013 1 次提交
-
-
由 Juergen Hoeller 提交于
Comprehensive update to the framework's TimeZone handling, including a new TimeZoneAwareLocaleContext and a LocaleContextResolver for Spring MVC A few noteworthy minor changes: LocaleContext.getLocale() may return null in special cases (not by default), which our own accessing classes are able to handle now. If there is a non-null TimeZone user setting, we're exposing it to all collaborating libraries, in particular to JSTL, Velocity and JasperReports. Our JSR-310 and Joda-Time support falls back to checking the general LocaleContext TimeZone now, adapting it to their time zone types, if no more specific setting has been provided. Our DefaultConversionService has TimeZone<->ZoneId converters registered. And finally, we're using a custom parseTimeZoneString method now that doesn't accept the TimeZone.getTimeZone(String) GMT fallback for an invalid time zone id anymore. Issue: SPR-1528
-