We're reviewing the content of our logs, and finding them cluttered with exceptions. When a user submits invalid data (with a large user base, often!) Orbeon still prints a full stack trace at the ERROR level, despite this not actually being an error.
This can't be fixed by fiddling with log4j, because a single Log4j logger (from XFormsServer) is used everywhere - setting it to FATAL will hide all sorts of real errors. I recall reporting this error some time ago, I think with a patch even. Orbeon needs to distinguish between validation errors and actual errors (as XForms should have in the first place!) and only log the former to DEBUG - probably to a separate logger. In general Orbeon has very 'chatty' logging.. for example in production XFormsServer has to be set to WARN or higher, otherwise you get two lines logged for every user request and interaction with a form. With a large user base this makes the log extremely difficult to use. I'd suggest logging this sort of information at the TRACE level. |
Administrator
|
Hi Adrian,
Sorry if we broke this: a lot of changes have been going on since your patch I believe. Re. validation errors, I committed a change so that those should now show at the debug level. We usually use the debug level for most of the logging. We could use trace instead. The boundary between trace and debug is not very clear. In either case it is meant for developers. Regarding the request logs, would that make sense to you as debug level as well? -Erik On Aug 13, 2008, at 1:47 PM, Adrian Baker wrote: > > We're reviewing the content of our logs, and finding them cluttered > with > exceptions. When a user submits invalid data (with a large user base, > often!) Orbeon still prints a full stack trace at the ERROR level, > despite > this not actually being an error. > > This can't be fixed by fiddling with log4j, because a single Log4j > logger > (from XFormsServer) is used everywhere - setting it to FATAL will > hide all > sorts of real errors. > > I recall reporting this error some time ago, I think with a patch > even. > Orbeon needs to distinguish between validation errors and actual > errors (as > XForms should have in the first place!) and only log the former to > DEBUG - > probably to a separate logger. > > In general Orbeon has very 'chatty' logging.. for example in > production > XFormsServer has to be set to WARN or higher, otherwise you get two > lines > logged for every user request and interaction with a form. With a > large user > base this makes the log extremely difficult to use. I'd suggest > logging this > sort of information at the TRACE level. > -- > View this message in context: http://www.nabble.com/Stack-trace-logged-on-invalid-submission-tp18970934p18970934.html > Sent from the ObjectWeb OPS - Users mailing list archive at > Nabble.com. > > > -- > You receive this message as a subscriber of the [hidden email] > mailing list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/ -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
Hi Erik - great!
Sorry I actually meant DEBUG instead of TRACE. I agree, fairly fine distinction between the two - usually easier to control things with different Loggers rather than the two levels. Request logs, yes I would suggest at DEBUG. Could default DEBUG on for this logger for the default distribution since it's obviously helpful + important when developing. Adrian
|
Administrator
|
Adrian,
Do you see a drawback leaving this at info, and then moving up the level to warn in production if you don't want to see these particular entries? -Erik On Aug 27, 2008, at 3:59 PM, Adrian Baker wrote: > > Hi Erik - great! > > Sorry I actually meant DEBUG instead of TRACE. I agree, fairly fine > distinction between the two - usually easier to control things with > different Loggers rather than the two levels. > > Request logs, yes I would suggest at DEBUG. Could default DEBUG on > for this > logger for the default distribution since it's obviously helpful + > important > when developing. > > Adrian > > > Erik Bruchez wrote: >> >> Hi Adrian, >> >> Sorry if we broke this: a lot of changes have been going on since >> your >> patch I believe. >> >> Re. validation errors, I committed a change so that those should now >> show at the debug level. >> >> We usually use the debug level for most of the logging. We could use >> trace instead. The boundary between trace and debug is not very >> clear. >> In either case it is meant for developers. >> >> Regarding the request logs, would that make sense to you as debug >> level as well? >> >> -Erik >> >> On Aug 13, 2008, at 1:47 PM, Adrian Baker wrote: >> >>> >>> We're reviewing the content of our logs, and finding them cluttered >>> with >>> exceptions. When a user submits invalid data (with a large user >>> base, >>> often!) Orbeon still prints a full stack trace at the ERROR level, >>> despite >>> this not actually being an error. >>> >>> This can't be fixed by fiddling with log4j, because a single Log4j >>> logger >>> (from XFormsServer) is used everywhere - setting it to FATAL will >>> hide all >>> sorts of real errors. >>> >>> I recall reporting this error some time ago, I think with a patch >>> even. >>> Orbeon needs to distinguish between validation errors and actual >>> errors (as >>> XForms should have in the first place!) and only log the former to >>> DEBUG - >>> probably to a separate logger. >>> >>> In general Orbeon has very 'chatty' logging.. for example in >>> production >>> XFormsServer has to be set to WARN or higher, otherwise you get two >>> lines >>> logged for every user request and interaction with a form. With a >>> large user >>> base this makes the log extremely difficult to use. I'd suggest >>> logging this >>> sort of information at the TRACE level. >>> -- >>> View this message in context: >>> http://www.nabble.com/Stack-trace-logged-on-invalid-submission-tp18970934p18970934.html >>> Sent from the ObjectWeb OPS - Users mailing list archive at >>> Nabble.com. >>> >>> >>> -- >>> You receive this message as a subscriber of the [hidden email] >>> mailing list. >>> To unsubscribe: mailto:[hidden email] >>> For general help: mailto:[hidden email]?subject=help >>> OW2 mailing lists service home page: http://www.ow2.org/wws >> >> -- >> Orbeon Forms - Web Forms for the Enterprise Done the Right Way >> http://www.orbeon.com/ >> >> >> >> -- >> You receive this message as a subscriber of the [hidden email] >> mailing >> list. >> To unsubscribe: mailto:[hidden email] >> For general help: mailto:[hidden email]?subject=help >> OW2 mailing lists service home page: http://www.ow2.org/wws >> >> > > -- > View this message in context: http://www.nabble.com/Stack-trace-logged-on-invalid-submission-tp18970934p19191407.html > Sent from the ObjectWeb OPS - Users mailing list archive at > Nabble.com. > > > -- > You receive this message as a subscriber of the [hidden email] > mailing list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/ -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
Free forum by Nabble | Edit this page |