Thanks for the detailed feedback.
First off, can you please re-download spring-webflow-2.0.m4.zip from sourceforge and retest? It appears an early version of M4 we uploaded, quickly deleted after a sanity test and replaced (before the release announcement), still propagated out to some people anyway [this is the second report I've had showing this]. Based on what you are seeing with your error messages, I suspect you may have this version . Getting a fresh M4 should resolve your #5.
As far as #4 goes, JBoss EL is used as the 'default EL implementation' for SWF *if it is picked up on the classpath*. This is a Unified EL implementation, the only one currently with enough features to meet the needs of SWF. If it is not on the classpath, OGNL is expected to be there - and if you don't have either you'll get a error message. No where ever should JBoss EL be required. Please let me know if you continue to have this problem - it's a JSP report, isn't it? Can you tell me what servlet container you are running on, what version of JSP, and what version of Java. I suspect this may be due us setting a special "default expression factory" system property too eagerly and Jetty is blowing up as a result.
#1, #2, and #3. The selection of a view by convention (defaulting to a .jsp extension at present) should only occur if you have *not* specified a view attribute in your view-state. The default behavior of resolving to a view resource in the flow working directory should only occur in a MVC environment if no view resolvers have been configured on the system-wide MvcViewFactoryCreator (a custom flow builder service--see the flow-builder-services tag for how to specify a custom bean instance). By default, no view resolvers are configured on the default MvcViewFactoryCreator so flow-relative view resource resolution kicks in without overriding this default. We should consider revisiting this default behavior for 2.0 RC1.
The motivation for favoring resolving views within a flow working directory is one of packaging. We see flows as logical modules and feel it makes a lot of sense to bundle them with their dependent artifacts (views, messages, etc). together. There needs to be a way to more easily override this default, probably, and we need to consider the impact on things like when you are using Tiles.
Last edited by Keith Donald; Mar 13th, 2008 at 03:06 PM.
Core Spring Development Team