Re: svn commit: r638774 - in /xmlgraphics/fop/branches/Temp_ProcessingFeedback/src/java/org/apache/fop/events: LoggingEventListener.java model/EventSeverity.java
On 20.03.2008 12:23:43 Vincent Hennebert wrote: > Jeremias Maerki wrote: > > Overconstrained geometry adjustment notifications were on debug level. I > > guess they could also be promoted to INFO level if that's preferred. > > It's an event I would want to get notified about but the severity level > > is discussable. > > I see. Well calling it debug looks a bit unfortunate to me. That blurs > the limit between the regular logging framework and the feedback > mechanism IMO. If the two are co-existing, which one to use then? > > I agree with you that this overconstrained geometry message is of enough > interest to be processed by the feedback mechanism. I’ll let you judge, > but I see the two following ways of handling that: > - either this piece of information is important enough to be promoted to > the INFO level. Then no need to add another level. > - or this message is still less important than the other INFO messages. > Then adding another level of importance makes sense but it should > really not be called debug, as it’s too misleading. What about minor? > Or fine, to mimic the java logging framework. I think it's better to promote it to INFO. DEBUG really doesn't make much sense. MINOR would indeed be better if this is necessary. > Will the feedback mechanism allow to disable events based on their ids? Of course. Just register your own listener and only forward what you like to any feedback/logging mechanism you want. The logging listener is only added if no other listener has been registered until the start of the processing run (as a fallback to keep the status quo as well as possible, see FOTreeBuilder.startDocument()). > Then if users are annoyed by some messages, they could simply customize > the framework to filter out events they are not interested in. While > this possibility doesn’t really shortcut the questioning above, it might > go along with keeping a reduced number of levels. > > As a side thought: what could make sense in the future is to group > events by families: overflow events, missing resources events, > font-related events, etc. That would allow to easily disable a family of > events you’re not interested in. I thought about that. This could easily be done by extending the event model by a category key. There is already an implicit grouping by event producer which will suffice for most cases, I think. If there is demand for an additional category this is easy to add. I didn't want to add too much at the beginning for something which 95% of the people don't need anyway. > WDYT? > Thanks, > Vincent > > > -- > Vincent HennebertAnyware Technologies > http://people.apache.org/~vhennebert http://www.anyware-tech.com > Apache FOP Committer FOP Development/Consulting Jeremias Maerki
Re: svn commit: r638774 - in /xmlgraphics/fop/branches/Temp_ProcessingFeedback/src/java/org/apache/fop/events: LoggingEventListener.java model/EventSeverity.java
Jeremias Maerki wrote: > Overconstrained geometry adjustment notifications were on debug level. I > guess they could also be promoted to INFO level if that's preferred. > It's an event I would want to get notified about but the severity level > is discussable. I see. Well calling it debug looks a bit unfortunate to me. That blurs the limit between the regular logging framework and the feedback mechanism IMO. If the two are co-existing, which one to use then? I agree with you that this overconstrained geometry message is of enough interest to be processed by the feedback mechanism. I’ll let you judge, but I see the two following ways of handling that: - either this piece of information is important enough to be promoted to the INFO level. Then no need to add another level. - or this message is still less important than the other INFO messages. Then adding another level of importance makes sense but it should really not be called debug, as it’s too misleading. What about minor? Or fine, to mimic the java logging framework. Will the feedback mechanism allow to disable events based on their ids? Then if users are annoyed by some messages, they could simply customize the framework to filter out events they are not interested in. While this possibility doesn’t really shortcut the questioning above, it might go along with keeping a reduced number of levels. As a side thought: what could make sense in the future is to group events by families: overflow events, missing resources events, font-related events, etc. That would allow to easily disable a family of events you’re not interested in. WDYT? Thanks, Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
Re: svn commit: r638774 - in /xmlgraphics/fop/branches/Temp_ProcessingFeedback/src/java/org/apache/fop/events: LoggingEventListener.java model/EventSeverity.java
Overconstrained geometry adjustment notifications were on debug level. I guess they could also be promoted to INFO level if that's preferred. It's an event I would want to get notified about but the severity level is discussable. See: http://svn.apache.org/viewvc?rev=638777&view=rev On 20.03.2008 11:17:34 Vincent Hennebert wrote: > Hi Jeremias, > > > Author: jeremias > > Date: Wed Mar 19 03:17:36 2008 > > New Revision: 638774 > > > > URL: http://svn.apache.org/viewvc?rev=638774&view=rev > > Log: > > Added DEBUG level. > > Why a debug level?? I thought the idea was to keep the current logging > framework for debugging purpose? > > Vincent > > > -- > Vincent HennebertAnyware Technologies > http://people.apache.org/~vhennebert http://www.anyware-tech.com > Apache FOP Committer FOP Development/Consulting Jeremias Maerki
Re: svn commit: r638774 - in /xmlgraphics/fop/branches/Temp_ProcessingFeedback/src/java/org/apache/fop/events: LoggingEventListener.java model/EventSeverity.java
Hi Jeremias, > Author: jeremias > Date: Wed Mar 19 03:17:36 2008 > New Revision: 638774 > > URL: http://svn.apache.org/viewvc?rev=638774&view=rev > Log: > Added DEBUG level. Why a debug level?? I thought the idea was to keep the current logging framework for debugging purpose? Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting