OK, thanks for the new jar, Luca. I see the source of the problem now. That
whole Session business was a bit of a red herring. Two things to look at:

1) The old SpringHibernateWorkflowStore did not correctly populate or use the
stepIndex column in the os_currentsteps table. I verified that creating
HibernateCurrentSteps using the old store results in a null value being stored
in this column.

The NewSpringHibernateWorkflowStore does utilize the column correctly. In my
case, that meant it crashed and burned the first time it tried to read the step
and picked up the null value from that column.

This does present a bit of a migration challenge for users moving to
NewSpringHibernateWorkflowStore. In my case, I fixed the problem by manually
populating the stepIndex column for all rows in my database. For large databases
with branching workflow, this may end up being difficult to infeasible.

2) In your Spring configuration file, you set singleton="false" on the
workflowTarget bean. It is considered unsafe to reuse the same instance of
BasicWorkflow indefinitely through the app, so presumably you are trying to get
a new instance on each invocation.

[b]You are not getting the semantics you expect here.[/b] On Spring startup, an instance of BasicWorkflow is created and bound to the
TransactionProxy defined as the workflow bean. That same instance is reused
every time the proxy is invoked, which is to say every time that the application
invokes the workflow bean. You are going to need to use method injection if you
want a new instance of BasicWorkflow to be instantiated everytime the user
references the workflow bean.

--------------------------------------------------------------------- Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=6965&messageID=17023#17023