Adrian,
Thanks, that sounds quite reasonable. Wouldn't it be enough to just
have the extra XFormsModelSubmission, and log the 404, etc. to the
usual XFormsServer logger?
-Erik
Adrian Baker wrote:
> I finally got around to doing this, since we couldn't deploy to
> production environments with the
> org.orbeon.oxf.xforms.processor.XFormsServer logger set to debug (far
> too verbose), but yet we were missing xforms-submit-error events which
> were silently causing forms to behave badly.
>
> What I've done is split out some of the XFormsServer debug calls to two
> other loggers:
>
> - org.orbeon.oxf.xforms.event.events.XFormsSubmitErrorEvent
> By default logs the *message only* of the exception causing an
> xforms-submit-error at INFO level. Setting to DEBUG will log the entire
> stack trace of the exception.
>
> - org.orbeon.oxf.xforms.XFormsModelSubmission
> By default logs nothing. Setting this to DEBUG will debug invalid
> instance documents.
>
> So this gives slightly finer control over logging & debugging XForms.
> The default settings should be roughly suitable for a production
> environment where you still want errors like a 404 (eg a remote server
> is down etc) logged, but little more. If you want to debug validation
> problems in a form the XFormsModelSubmission logger can be used for
> this, without necessarily having to go to the level of XFormsServer,
> which logs every instance document every time there's an interaction
> (useful in it's on right, but makes it hard to pick stuff out of the
noise).
>
> The downside is is that by default you will get a INFO message every
> time someone tries to submit a form with invalid data, but this comes
> back to the general XForms issue of detecting whether
> xforms-submit-error is caused by a remote server issue or a validation
> issue.
>
> Adrian
--
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/
opensubscriber is not affiliated with the authors of this message nor responsible for its content.