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 Hennebert Anyware Technologies > http://people.apache.org/~vhennebert http://www.anyware-tech.com > Apache FOP Committer FOP Development/Consulting Jeremias Maerki