5 Spring pitfalls

There are those days that you think everything (especially your computer) is against you, that nothing works and there is nothing else to blame but the existence of mankind. You seem to be in some dark wormhole in which mother nature decided to change the rules, it is all different now! Things happen that are just impossible!

Using the Spring framework for quite some time now, I had some of those days. You keep staring at your code but if there is one thing certain, it is that you are right and what happens is just impossible. So I collected some of those fuzzy issues which can take hours to find out what's really happening. To make it a little bit interactive, I will post the answers in the second part of this blog in a few weeks. The fuzzy issues are illustrated below by code examples followed by multiple choice questions. Can you tell what will happen?

Fuzzy issue 1

Take a look at the following code snippet in the Form Backing Object of your panel. The Form Backing Object implements a toString(), just for logging purposes. That cannot possibly be wrong, can it?

public class MyFBO implements FormBackingObject {
  ...
  public String toString() {
    String bla = "";
      for (int i=0; i<5000; i++) {
        bla += "bla";
      }
    return bla;
  }
}

Question: what will happen here?

A. This large String somehow suddenly appears in the generated HTML of the panel.

B. An Exception is displayed in the Tomcat console and the panel doesn't open at all.

C. Initially the panel seems to works fine but after submitting once you get a blank page. No errors visible in Tomcat. The panel seems to have died.

Fuzzy issue 2

Controller delegation is a powerful concept. In the code snippet below the tabController from WCB 1 delegates Spring controller methods to a subTabController from WCB 2. Controller delegation is required here to ensure that language labels coming from WCB 2 are displayed properly.

public class MyController extends ComponentController {
  ...
  public void initializeTabSet(HttpServletRequest request, PanelBase panel)
    MyTabController tabController = getStatefulTabController(MyTabController.class, request);
    MySubTabController subTabController = getStatefulTabController(MySubTabController.class, request);
    // Add a tab
    addTab("bla", "panel.bla", "", "bla.jspf", myTabController, PanelTabset.LEVEL1_HORIZONTAL, request);
    // Delegate controller methods to the subtab controller
    tabController.addControllerDelegation(subTabController, fbo, request);
  }
}

Question: what will happen here?

A. Each change in WCB 2 will only be effective after a restart of Tomcat. Updates will not effect the running WCB anymore.

B. The language labels of WCB 2 will be overruled by those of WCB 1.

C. This causes an endless recursion; the tabController invokes the subTabController and vice versa.

Fuzzy issue 3

The following code snippet below comes from a simple panel with a stateful Form Backing Object. Nothing can be wrong with this, can it? This is business as usual! Take a look at this implementation of showForm of the controller:

public class MyController extends ComponentController {
  ...
  public ModelAndView showForm(HttpServletRequest request,
            HttpServletResponse response, BindException errors, Map controlModel)
            throws Exception {
    ModelAndView modelAndView = super.showForm(request, response, errors, controlModel);
    if (myFBO.getSelectedEntityId() != null) {
      BeanUtils.copyProperties(myEntityManager.find(myFBO.getSelectedEntityId()), myFormBackingObject);
    }
    return modelAndView;
  }
}

Question: what will happen here?

A. If one field in the form fails to bind or validate all entered or changed values by the editor are lost and the form reopens in the previous state. You wonder how this can happen since the form backing object is supposed to be stateful.

B. If one field in the form fails to bind or validate the onSubmit and showForm are invoked within the same request. You wonder how this can happen since WebManager is supposed to use the post and redirect pattern.

C. If one field in the form fails to bind or validate some properties are updated, some are not.

Simply registering a validator in the initBinder() of the controller seems to be very simple. Just like this:

public class MyController extends ComponentController {
  ...
  public void initBinder(HttpServletRequest request,
        ServletRequestDataBinder binder) throws Exception {
        super.initBinder(request, binder);
    // Add a date validator to only accept dates in the past
    addValidator(new PastDateValidator());
  }
}

Question: what will happen here?

A. The validator is not invoked at all.

B. Each a time a user submits this panel the validation is invoked one more time, but only for this user. If the user submitted the panel 10 times, the validation is performed 10 times (with the same result).

C. Validation always fails.

Spring binding can be more complex then you think. Consider the following example used in a panel:

 public class MyFBO implements FormBackingObject {
   ...
   private User myUser;
   public User getUser() {
     if (myUser == null) {
       myUser = new User();
      }
      return myUser;
  }
  public String getName() {
    return myUser.username;
  }
  public void setName(String name) {
    myUser.username = name;
  }
  class User {
    String username;
      public void setUserName(String name) {
        username = name;
      }
      public String getUserName() {
        return username;
      }
   }
 }

(In the JSP)

...
<wmedit:input path="command.user.userName"/>
<wmedit:input path="command.name"/>

Question: what will happen here?

A. This doesn't work and will cause an Exception upon opening the panel.

B. This doesn't work but it will if the property 'name' is renamed to 'zname' (so methods getZname, setZname and bind on command.user.zname in the JSP).

C. This doesn't work but if you rename User to Auser (so getAuser and bind on command.auser.userName), it will.