Announcement Announcement Module
No announcement yet.
Spring Web Flow 2.2.1 is out, Spring Web Flow 2.3.0 next Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Web Flow 2.2.1 is out, Spring Web Flow 2.3.0 next

    A minor maintenance release 2.2.1 is available for download. See the changelog for a list of issues included. Meanwhile development has began towards a Spring Web Flow 2.3 release.

  • #2
    Spring webflow upgrade from webflow 1.x version to 2.x


    Currently our project is running on spring web flow 1.x version. We are planning to upgrade to web flow 2.x latest version. Do you have any idea? what will be the impact? could you help me on this?

    Thanks in advance

    Thanks & Regards


    • #3
      You can check the reference guide.
      Chapter 16. Upgrading from 1.0



      • #4
        2.3.0 when??

        Out of curiosity, when is 2.3.0 expected to become available?

        Unfortunately we've hit the SWF-1437 bug "Two concurrent threads in an expression of a flow override the root object of evaluation context", and our release deadline is very near.

        Or, what about a 2.2.2 version with this bug fixed?



        • #5

          I have the same questions. When will 2.3 be out?
          I need issue (in 2.3.0 release) to be fixed.

          Would be nice to have some dates here.



          • #6
            Saw that SWF-759

            is getting resolved. Looks like one would be able to inject custom conversation manager. But is there a solution to inject custom flow execution repository?. There are certain tweaks we need to do and hence the question. Thx


            • #7
              Good article on Spring Web Flow (SWF)


              • #8
                Validation Groups for Spring 2.3.0


                (Sorry - subject should read Spring Webflow 2.3.0)

                I've been looking through the 2.3 maintenance branch and can't see any mention of how to specify JSR-303 validation groups for model validation. Will this be supported? It is in important feature of the JSR-303 API....

                Last edited by Paul Wilson; Feb 28th, 2011, 08:47 AM. Reason: Mistake in Subject


                • #9
                  Web Flow 2.3 won't have explicit support for validation groups as the underlying LocalValidatorFactoryBean in Spring MVC doesn't have that built in yet either (SPR-7062).

                  For partial validation you best bet is to continue using validation by convention -- i.e. validate{viewStateId}(ValidationContet). Optionally you could inject an extension of the LocalValidatorFactoryBean with an additional validate method that expects groups.


                  • #10
                    I'm not convinced. The JIRA you provided is for the @Valid annotation specifically and I don't think that even Hibernate Validator supports that.

                    Why can't you cast LocalValidatorFactoryBean to javax.validation.Validator (if it is an instance of) and use that within the Validation helper along with any groups provided?
                    Last edited by Paul Wilson; Feb 28th, 2011, 10:16 AM. Reason: Type (JSR -> JIRA)


                    • #11
                      That issue will also result in changes to SpringValidatorAdapter. That aside how do you imagine specifying validation groups for a given view state?


                      • #12
                        Correct me if I'm wrong, but SpringValidatorAdapter already has:

                        public <T> Set<ConstraintViolation<T>> validate(T object, Class<?>... groups) {
                        		return this.targetValidator.validate(object, groups);
                        I'm writing a framework off of Webflow that allows validation groups to be specified using the fully qualified class name separated by commas. I split it and use the class loader to find groups by their name. I then collate them and pass them to the groups parameter [1]. I know that Seam remoting allows you to specify only the unqualified name which is much cleaner [2], but I don't know how it determines the correct type to use in this case.

                        I imagine a neater way would be to define them within the view as a separate element similar to the way the 'binding' element operates?


                        [1] This is a bit tricky because 'groups' is an array of a generics but it is possible.
                        Last edited by Paul Wilson; Feb 28th, 2011, 10:54 AM. Reason: Bad formatting


                        • #13
                          Yes SpringValidatorAdapter does implement all javax.validation.Validator methods. However, the one invoked from ValidatorHelper is:

                          public void validate(Object target, Errors errors) { }
                          The above method adapts Bean Validation errors and registers them with the Spring MVC Errors instance passed in. This way errors raised via JSR-303 validation can be treated as any other validation errors in Spring MVC with regards to being displayed through the form:errors tag or customized through the default MessageCodesResolver.

                          Following the conventions approach used presently to discover validation methods and validator objects, we could try to come up with some suitable convention. Alternatively a view state attribute named "validationGroups" could be expected. The value would either be fully qualified class names or unqualified with the package of the model assumed by default. I suppose the common case would be one validation group per view state so even fully qualified wouldn't be too bad.

                          If you don't mind please raise a ticket in JIRA as that would be a better place to capture this conversation.


                          • #14