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

> Thanks,
> Vincent
> -- 
> Vincent Hennebert                            Anyware Technologies
> http://people.apache.org/~vhennebert         http://www.anyware-tech.com
> Apache FOP Committer                         FOP Development/Consulting

Jeremias Maerki

Reply via email to