- 08 9月, 2010 8 次提交
-
-
由 Chris Beams 提交于
Before: - new GenericXmlApplicationContext("com/acme/path/to/resource.xml"); - GenericXmlApplicationContext ctx = new GenericXmlApplicationContext(); ctx.load("com/acme/path/to/resource.xml"); ctx.refresh(); After: - The above remain supported, as well as new class-relative variants - import com.acme.path.to.Foo; new GenericXmlApplicationContext(Foo.class, "resource.xml"); - import com.acme.path.to.Foo; GenericXmlApplicationContext ctx = new GenericXmlApplicationContext(); ctx.load(Foo.class, "resource.xml"); ctx.refresh(); These changes are generally aligned with signatures long available in ClassPathXmlApplicationContext. As GenericXmlApplicationContext is intended to be a more flexible successor to CPXAC (and FSXAC), it's important that all the same conveniences are available.
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
fixed @mvc processing of parameter-level annotations to work with interface-based proxies again (SPR-7483)
-
由 Juergen Hoeller 提交于
revised @RequestParam processing to support CSV-to-array/collection binding with ConversionService (SPR-7479)
-
由 Arjen Poutsma 提交于
-
由 Juergen Hoeller 提交于
revised @RequestParam processing to support CSV-to-array/collection binding with ConversionService (SPR-7479)
-
由 Arjen Poutsma 提交于
-
由 Arjen Poutsma 提交于
-
- 07 9月, 2010 12 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
DispatcherPortlet copies all action parameters to render parameters in case of an action exception (SPR-7495); shortened Portlet MVC's action exception render parameter value to "true"
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
allow for writing the response directly in a Portlet @ExceptionHandler method (like in the Servlet equivalent)
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
- 03 9月, 2010 1 次提交
-
-
由 Arjen Poutsma 提交于
-
- 02 9月, 2010 8 次提交
-
-
由 Sam Brannen 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
DefaultLobHandler's "wrapAsLob" mode works with PostgreSQL's getAsciiStream() requirement (SPR-7487)
-
由 Juergen Hoeller 提交于
consistent use of JDK 1.5's ThreadLocal.remove() over ThreadLocal.set(null), preventing leaks (SPR-7441)
-
- 01 9月, 2010 5 次提交
-
-
由 Juergen Hoeller 提交于
JaxWsPortClientInterceptor does not fall back to annotation-specified name as portName anymore (SPR-7505)
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
- 31 8月, 2010 3 次提交
-
-
由 Arjen Poutsma 提交于
-
由 Arjen Poutsma 提交于
-
由 Arjen Poutsma 提交于
-
- 27 8月, 2010 2 次提交
-
-
由 Arjen Poutsma 提交于
-
由 Chris Beams 提交于
GenericApplicationContext and AbstractRefreshableApplicationContext implementations now call DefaultListableBeanFactory.setSerializationId() only upon successful refresh() instead of on instantiation of the context, as was previously the case with GAC. DLBF.setSerializationId() adds the beanFactory to the *static* DLBF.serializableFactories map, and while calling close() on the application context removes entries from that map, it does so only if the context is currently active (i.e. refresh() has been called). Also, cancelRefresh() has been overridden in GAC just as it has been in ARAC to accomodate the possibility of a BeansException being thrown. In this case, the beanFactory serializationId will be nulled out and the beanFactory removed from the serializableFactories map. The SerializableBeanFactoryMemoryLeakTests test case provides full coverage of these scenarios.
-
- 25 8月, 2010 1 次提交
-
-
由 Arjen Poutsma 提交于
-