Andreas, what I was talking about was exlusively logging targeted at the developer, not the user. User feedback is a different topic, one that I want to address early next year for FOP (see [1]), but I've mentioned that before.
[1] http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback I agree with what Max said. I really don't want to build an abstraction for an abstraction. JCL is good enough and I can't remember any calls from users asking us to find a different solution because they ran into serious problems. Mostly it's just about configuring JCL which is usually no problem. And the other problem is that we don't currently have an answer for processing/user feedback, at least since we switched from Avalon Logging to JCL. But before that we mixed the two aspects which was bad also. On 16.12.2007 10:51:22 Andreas L Delmelle wrote: > > On Dec 16, 2007, at 10:25, Max Berger wrote: > > > Andreas, > > > >> How about using a very basic message handling system, to which > >> users can plug in any bridge (like JCL) or specific implementation > >> (like log4j) of their choosing? > >> On the Commons side, this would mean at most a handful of > >> proprietary classes/interfaces, one to which all messages are routed. > >> Users can subclass/implement that interface to decide what to do > >> with them in their particular context. > >> Commons' own default implementation would simply send the messages > >> to System.out or System.err, thereby removing any dependency on a > >> specific logging framework whatsoever. > > > > What you are describing is exactly commons-logging :). > > Not really what I had in mind, or IOW: Yes, with a big BUT... > > There is a difference between a Logger.warn() message, which I take > to be meant for developers to help debug certain issues, and > ErrorListener.warning(), which is specifically meant for the external > application and the end-user. > I see JCL only as an abstraction for the former, not the latter. > > > The only addition that commons-logging has is a very sophisticated > > (and highly criticized) auto-detection mechanism which detects the > > type of logging framework currently in use and will auto-plugin is > > specific handler. > > OK, and users could still opt for this solution. Only difference is: > we would not be forcing the dependency on JCL down their throat, so > to speak. > > > Andreas Jeremias Maerki --------------------------------------------------------------------- Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
