• Bug
  • Status: Closed
  • 1 Critical
  • Resolution: Fixed
  • Integration Modules
  • nrana
  • Reporter: asingh
  • November 09, 2009
  • 0
  • Watchers: 1
  • January 14, 2010
  • November 19, 2009

Description

Forum issue: http://forums.terracotta.org/forums/posts/list/0/2540.page

How to reproduce: Run sample attached in forum issue with tc.

The exception should be probably snipped to cut away classes that are not needed so that we don’t fall into a recursive loop of adding various classes in the include section. Adding classes such as org.springframework.web.context.support.XmlWebApplicationContext, org.springframework.web.context.support.AbstractRefreshableWebApplicationContext, org.springframework.context.support.AbstractRefreshableConfigApplicationContext, org.springframework.context.support.AbstractRefreshableApplicationContext, org.springframework.context.support.AbstractApplicationContext, org.springframework.core.io.DefaultResourceLoader in the include section may not be desirable.

One thing that I don’t understand is that the transition happens even when there is an exception when binding the model. It should just re-render the view as suggested by the last para at http://static.springsource.org/spring-webflow/docs/2.0.x/reference/html/ch04s06.html

Comments

Abhishek Singh 2009-11-19

Fixed in rev-19445 (19446 for tc-3.1).

Spring web-flow puts the mapping results in flash-scope when there are any errors in binding/mapping. And the mapping results object graph contains references to the HttpServletRequest (upto TerracottaSessionManager and related classes) and FlowDefinition’s (which reaches up to the application context definitions etc). Adapted AbstractMvcView to put null instead of the mapping-results when there are errors in binding. This potentially can lead to loss of exceptions that happened in binding (don’t knw actually if the mapping-results that are put in flash scope are retrieved and used by webflow somewhere else). Otherwise users should be following http://static.springsource.org/spring-webflow/docs/2.0.x/reference/html/ch04s09.html to provide specific bindings for their models explicitly anyways (which should remove any chances of mapping-results anyway).

Answering my own question above as to why the transition still happens when there are exceptions in binding, webflow actually checks that if the exception are only TargetAccessErrors (propertyNotFound for attributes that are not present in the model), it ignores them and transitions to the next state.

Nitin Rana 2009-12-16

verified with Terracotta 3.2.0, as of 20091212-151202 (Revision 14206 by cruise@su10mo5 from 3.2)