Announcement Announcement Module
Collapse

Spring Modules forum decommissioned in favor of Spring Extensions

As the Spring Modules project has been replaced by the Spring Extensions (http://www.springsource.org/extensions) project, this forum has been decommissioned in favour of Spring Extensions one at:
http://forum.springsource.org/forumdisplay.php?f=44

Please see the Spring Extensions home page for a complete list of current projects in Java, .NET and ActionScript. You can also propose one if you want.

Cheers,
Costin Leau
SpringSource - http://www.SpringSource.com- Spring Training, Consulting, and Support - "From the Source"
http://twitter.com/costinl
See more
See less
[XT Ajax] IllegalArgumentException: setAttribute: Non-serializable attribut Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • [XT Ajax] IllegalArgumentException: setAttribute: Non-serializable attribut

    Hi,

    Getting an exception due to non-serializable attribute.

    Come from where the errors are stored in the Session here (from DefaultValidationHandler.java):

    private void putNewErrors(AjaxSubmitEvent event, AjaxResponseImpl response) {
    Errors errors = event.getValidationErrors();
    ...
    logger.debug("Putting errors in session for URL: " + request.getRequestURL().toString());
    request.getSession(true).setAttribute(this.getErro rsAttributeName(request), errors);

    Outputting the Errors instance to the logs it is of class EscapedErrors:
    [org.springframework.web.bind.EscapedErrors@37eaab] which isn't Serializable.

    Wasn't getting this problem before, and very recently upgraded from Spring 2.0.3 to 2.0.6 so am thinking maybe they changed the Errors implementation used.

    Am investigating further and looking for a quick workaround. Thought I'd post here now in case anyone else has come across this.

    Cheers,
    D.

  • #2
    > recently upgraded from Spring 2.0.3 to 2.0.6 so am thinking maybe they changed
    > the Errors implementation used.

    That was a red herring. EscapedErrors is used as a wrapper (and always was) when using defaultHtmlEscaping, see org.springframework.web.servlet.support.RequestCon text

    Problem must have been introduced when I made the application distributable, thus requiring all Session attributes to be serializable.

    Now to find a solution ...

    Comment


    • #3
      Originally posted by derek View Post
      Problem must have been introduced when I made the application distributable, thus requiring all Session attributes to be serializable.
      Now to find a solution ...
      Hi Derek,

      thanks for pointing it out.
      It was my fault, as everything put in the HTTP session must be serializable, so can you open a Jira issue about that?
      I'll start working at it ASAP.

      Thanks again,
      Cheers,

      Sergio B.

      Comment


      • #4
        Hi Sergio,

        Thanks.

        JIRA issue opened: http://opensource.atlassian.com/proj...browse/MOD-385

        By the way, any estimate on when 0.9 is due.

        Cheers,
        Derek

        Comment


        • #5
          Originally posted by derek View Post
          By the way, any estimate on when 0.9 is due.
          SM 0.9 is due by the first week of September.

          However, I'll resolve this bug ASAP, so that you'll be able to use the latest 0.9 nightly build.

          Cheers,

          Sergio B.

          Comment


          • #6
            OK. By the way, I was obliged to implement my own ValidationHandler as, when there are field errors I also include an action to display a message at the top of the page alerting the user to the field errors below. The DefaultValidationHandler didn't have an extension point where I could add that. Perhaps quite a common requirement.

            Wouldn't have needed to write my own if it had another callback, say a PageErrorRenderingCallback with methods like:

            public Component[] getErrorComponents(AjaxSubmitEvent event, List allErrors, MessageSource messageSource, Locale locale);

            public AjaxAction[] getErrorActions(AjaxSubmitEvent event, List allErrors);

            What do you think?

            Derek

            Comment


            • #7
              Originally posted by derek View Post
              The DefaultValidationHandler didn't have an extension point where I could add that. Perhaps quite a common requirement.
              What about https://springmodules.dev.java.net/s...deringCallback ?

              Please note that the ErrorRenderingCallback class has been slightly modified in the upcoming 0.9 release, so take a look at the new source code, too.

              Let us know if it fits your requirements.
              Cheers,

              Sergio B.

              Comment


              • #8
                The ErrorRenderingCallback is called once for each error. I want that but I also want to add some components/actions once only per response so long as there is 1 or more errors.

                Comment


                • #9
                  Originally posted by derek View Post
                  The ErrorRenderingCallback is called once for each error. I want that but I also want to add some components/actions once only per response so long as there is 1 or more errors.
                  We could add another method to the ErrorRenderingCallback executed only one time per response, something like:

                  Code:
                  public AjaxAction[] getGlobalErrorActions(AjaxSubmitEvent event);
                  What do you think?
                  If you think it's ok, please open a Jira issue about that.

                  Cheers,

                  Sergio B.

                  Comment


                  • #10
                    That would be ok, except there is also a need to do some clean up work in removeOldErrors(...). Would be tricky to provide a generic solution that would be able to determine what to clean up.

                    Another approach would be to make putNewErrors(...) and removeOldErrors(...) protected instead of private, then I could just extend the class override these with additional logic and call super.put...(...)

                    I'll open a JIRA for that.

                    Comment


                    • #11
                      Originally posted by derek View Post
                      That would be ok, except there is also a need to do some clean up work in removeOldErrors(...). Would be tricky to provide a generic solution that would be able to determine what to clean up.

                      Another approach would be to make putNewErrors(...) and removeOldErrors(...) protected instead of private, then I could just extend the class override these with additional logic and call super.put...(...)

                      I'll open a JIRA for that.
                      You have good points.

                      Please open the Jira issue: we'll continue there our discussion, because we are OT here.

                      Cheers,

                      Sergio B.

                      Comment


                      • #12
                        Fixed!
                        Please let me know if it works now.

                        Cheers,

                        Sergio B.

                        Comment


                        • #13
                          Fixed!
                          Please let me know if it works now.
                          Hi Sergio,

                          That's great, thanks.

                          I've read the code and it looks ok, would be much easier for me to test if MOD-386 was fixed too though .

                          Cheers,
                          Derek

                          Comment

                          Working...
                          X