A form won't magically re-submit itself unless there's JavaScript that submits it or the user submits it.
The code you're posting is *very* difficult to decipher: it's doing *way* to much in a single method. Even with the code elided it's still difficult to understand the code's intent because there are blocks of code that do nearly the exact same thing. If you simplify the code, group related functionality together, and so on, that will go a long way in helping you to understand what's actually happening.
Here's a trivial example where the cognitive/syntactic noise overwhelms the ability to think clearly:
I have to read *every* line of *both* blocks to try to figure out the intent. Only then is it obvious that almost nothing is different, and it would be more clearly expressed as this:
It also highlights a possible error in the original code; the "verifyFlag" request attribute is set regardless of the verifyFlag boolean value. Is that correct? I have no idea--it's hard to understand the code.
The original enrollCustomer() method is 200 lines long. By way of comparison, the *default* maximum method length in Checkstyle is 150. Lots of people get pretty twitchy when methods are longer than significantly less than that (myself included). Methods should strive to do one thing, and do it well. This makes them easier to understand (we spend more time *reading* code than writing it, and should optimize accordingly), easier to
test, and so on.
Here's a trivial example of this concept applied to enrollCustomer():
Right off the bat we see that the method is already doing too much, and things are in a confusing order. "Enrolling a customer" *depends* on "validating the form", but that doesn't mean that the entirety of "validating the form" belongs embedded in the enrollment itself--a prime candidate for refactoring. This also allows us to test the validation method in isolation.
One possible way to clarify this portion of the original method might be something like this (with the caveat that normally you'd just create an error message list and display it in a JSP rather than doing it by hand). It also highlighted a possible bug in the validation logic--if both values are null only one message would have been recorded.
(Mind that there are probably syntax or copy/paste errors, but you get the idea.) The rules of whitespace apply to source code at least as much as the printed page, btw--and it's arguably even *more* important considering the nature of code comprehension.
Once the cognitive/syntactic noise is lessened it's far, *far* easier to understand what's happening, when, and why.