Hi Adrian,

It is not forgotten. At least not completely :). But just to make,
let's create an entry in the tracker about this:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=305949&group_id=168&atid=350207

Alex

On 8/6/06, Adrian Baker <adrian.baker@orio...> wrote:
>
>  Did this get forgotten at some point, or was it decided that
> xforms-submit-error should not result in a log message?
>
>
>  Adrian Baker wrote:
>  Log to XFormsServer at info level you mean? That would work, sure. But the
> disadvantage would be that if you wanted to suppress xforms-submit-error
> messages being logged you also have to suppress all other INFO level
> XFormsServer messages.
>
>  Adrian
>
>  Erik Bruchez wrote:
> 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
>
>  ________________________________
>
>
> --
> You receive this message as a subscriber of the ops-users@obje...
> mailing list.
> To unsubscribe: mailto:ops-users-unsubscribe@obje...
> For general help: mailto:sympa@obje...?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>
> ______________________________________________________________________
>  This email has been scanned by the MessageLabs Email Security System.
>  For more information please visit
> http://www.messagelabs.com/email
> ______________________________________________________________________
>
> ________________________________
>
>  -- You receive this message as a subscriber of the ops-users@obje...
> mailing list. To unsubscribe:
> mailto:ops-users-unsubscribe@obje...
>  For general help: mailto:sympa@obje...?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>
> --
> You receive this message as a subscriber of the ops-users@obje...
> mailing list.
> To unsubscribe: mailto:ops-users-unsubscribe@obje...
> For general help: mailto:sympa@obje...?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>


--
Blog (XML, Web apps, Open Source):
http://www.orbeon.com/blog/