1 Reply Latest reply on Jun 26, 2009 2:40 PM by Brett Cave

    ajax4jsf + form submittal not working for a few hours after deply

    Brett Cave Newbie
      Really puzzled by this, cant find a logical solution to this....

      Have a jsf page:

      <h:form id="signupform">
        <s:validateAll>
          <!-- a few input fields -->
          <s:decorate id="usernameValidation" template="mytemplate.xhtml">
            <h:inputText value="#{signup.register.username}" required="true" validator="usernameValidator">
               <a:support event="onblur" reRender="usernameValidation" bypassUpdates="true" ajaxSingle="true" />
            </h:inputText>
          </s:decorate>
        </s:validateAll>
      </h:form>

      We have 2 x environments that we deploy to - 1 test and 1 x live. When we deploy to test, everything works fine, but when we deploy this to production, none of our forms work for a few hours.

      I have disabled all caching - the problem persists across browser cache deletes and jboss server restarts.... no forms or validation works at all for about 8 hours (but only after a new EAR is built and deployed to jboss).


      any ideas? been battling with this for days now :(
        • 1. Re: ajax4jsf + form submittal not working for a few hours after deply
          Brett Cave Newbie
          was a timezone issue.

          our development takes place in a GMT+2 timezone (developer workstations are set to this).
          the build server is configured on a GMT-7 timezone, but the file modification time (checked via the "stat" command was set to the GMT+2 time but on the -0700 time zone

          Access: 2009-06-26 04:12:52 -0700
          Modify: 2009-06-26 11:50:46 -0700
          Change: 2009-06-26 04:12:25 -0700

          jsf was not rendering correctly until time caught up. because jsf logs everything to stderr, we had set the logging of STDERR on our production AS to be exluded (as everything was logged to stderr, which the AS logs as ERROR, including info, debug and error logs). so we missed the logs about this error (and it wasnt even a very specific error)

          the issue is resolved by setting facelets.refresh_period to -1.