Migrating from 1.0 to 2.0

[habuma]

I've been migrating a simple 1.0 flow to work in 2.0-m4. No surprise that this effort has been met with a few bumps in the road.

In any event, I have a few questions/issues that I couldn't seem to find answers for elsewhere. Perhaps Keith or some other SWF 2.0 expert can help...

1. In 1.0, the view attribute of <view-state> referred to a logical view name that would be resolved to a JSP (or whatever) by a view resolver configured in the Spring context. But if I keep the view attribute in my flow definition with 2.0, I get a weird error indicating that it wants a [.jsp] view. If I change the view name from "registerUser" to "registerUser.jsp" it works without complaint...except...

2. The view name seems to refer to a specific JSP, not to a logical name to be resolved by a view resolver. Furthermore, it refers to not just any JSP called "registerUser.jsp"--that file must be in the same directory as the flow definition itself. Is there no way to specify a logical view name and have it resolved by a view resolver?

3. Even though my flow controller is configured in the Spring context alongside and just like my other controllers, for some reason it isn't getting wrapped in my Tiles template. Oh wait...that's probably because the view isn't getting resolved by my InternalResourceViewResolver that's using a TilesJstlView. This seems to be a problem associated with item #2.

4. If I use JSP EL in any of the JSPs that are views for my flow, I get a weird exception: "javax.el.ELException: Provider org.jboss.el.ExpressionFactoryImpl not found". For what it's worth, I'm running this in Jetty, not JBoss. Why is it complaining about a JBoss class?

5. I have a bean called "formActions" that is a o.sf.wf.action.FormAction. In my flow, under the view state, I have an <on-render> with an <evaluate> whose expression is "formActions.setupForm". This looks the same as what I see in the booking example, but when I try to go to that view state I get an exception claiming that there is no such property as o.sf.wf.engine.impl.RequestControlContextImpl.form Actions. I honestly don't understand what I'm doing wrong here, as it looks very much like what I see in the example flow.

Your help is greatly appreciated.

[Keith Donald]

Hi Craig,

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.

Keith

[habuma]

Not a problem...I'll redownload and try again. But would it be possible to push the fixed M4 JARs to the Maven milestone repository? I'm building with Maven and it'd be awful convenient to just use whatever version is in the Maven repo. Alternatively, perhaps the nightly build could be pushed into the Snapshot repository?

I'll get back to you on my findings.

[Keith Donald]

We're updating the existing M4 .JARS in the milestone repo to be on the safe side. I'll let you know when the update is in.

Keith

[jeremyg484]

#4 should be fixed now in SVN (see http://jira.springframework.org/browse/SWF-531) and the fix should appear in tonight's build.

Also, we are working on getting the nightly builds flowing into the snapshot repository, but this may not happen until next week.

- Jeremy

[habuma]

First off, can you please re-download spring-webflow-2.0.m4.zip from sourceforge and retest? ... Getting a fresh M4 should resolve your #5.

I shoved a newer version of the spring-webflow-2.0-m4.jar file into my local Maven repository and tried again. It seems to have resolved my problem with #5, as you suggested. Thanks.

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.

I do have OGNL in the classpath, so I'm not sure why I'm getting the error. Perhaps my expression isn't valid OGNL (I think it is, though)...even then, it shouldn't complain about JBoss EL, should it? I'll keep tinkering with it.

In the meantime, my container is Jetty 6, using the Jetty plugin for Maven (so that I can start it as part of my build) on a MacBook Pro, with the latest Java 5 available for Mac. I've not yet tried throwing it into Tomcat to see if it behaves differently...I'll try that later and report back.

...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.

That makes sense. And I was considering moving my flow out of my main web project once I get the wrinkles ironed out. In any event, though, the Tiles problem would remain. I suppose that I could try SiteMesh to see if I have any better luck...but I still think it should work with Tiles.

I'll also try overriding that default and will report on my progress.

[Keith Donald]

Craig,

The Maven repository M4 JARs have been updated now in the milestone repo. I'll post another thread letting people know they should clear out their caches and re-download if using Maven.

Thanks

Keith

[Keith Donald]

Okay so just to recap here.
Of Craig's reports #5 was a jar version problem (now resolved) and #4 was a bug that has now been fixed. The #1 through #3 is expected behavior with M4, not necessarily a problem, but we need to consider the impact on layout engines like Tiles for RC1 and we should look to simplify use of externally defined view resolvers for flow view resolution when that is desired. We'll open a JIRA to track this. Our sample Spring Travel MVC app already uses Tiles to a basic degree so we're in a good position to address this for RC1.

We should also be seeing 2.0 RC1 nightly snapshots in our repo soon too for Maven users.

Keith

[habuma]

Recapping from my end: As Keith said, #5 seems to have been fixed by using a newer and better 2.0-m4 JAR. #4 was a bug that was fixed (apparently in response to SWF-531). To confirm that #4 was fixed, I have tried the latest nightly build and it solved my problem.

So, now I'm left with a problem where my web app's view resolver is not being used to resolve SWF views (#1-#3). As Keith says, this is expected behavior, but it does cause problems for apps (like mine) that are using InternalResourceViewResolver along with a TilesJstlView to wrap their views with a Tiles template.
We should also be seeing 2.0 RC1 nightly snapshots in our repo soon too for Maven users.

I'll eagerly await a response to my Tiles problem, but while waiting will see if I can find a workaround. If a workaround is found, I'll share it here and/or as a patch to SWF.

Also, thanks to Keith and whoever else is responsible for addressing these problems and for taking steps to get the nightly builds into the SNAPSHOT maven repository.

[Keith Donald]

Craig,

The workaround is pretty straightforward:

Define a bean in your web context of type org.springframework.webflow.mvc.MvcViewFactoryCrea tor. Set the viewResolvers property to be your view resolver(s). Then, define a custom "flow-builder-services" tag and set its view-factory-creator attribute to reference your instance. Finally, wire the reference to your flow-builder-services instance into your flow-registry using the flow-builder-services attribute. Not as easy as it needs to be, but it should work.

Thanks

Keith