Re: [proposal] How to do logging from the command line (was: Re: Logging of exception.)
Just giving my opinion--I also recognize that the output interface is a bit rough, as Finn was saying, and may still need some work, possibly along the lines of what you were suggesting. Glen --- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > OK, forget it. I'm obviously worse at explaining > things than I thought. > I don't have the time to chew this through. It > should have been quick > and painless, but obviously it isn't. Hopefully, > someone else has a > better solution. > > I'm sorry for wasting your time writing this answer. > Back to my JNI > wrapper for FOP... > > Jeremias Maerki > >
Re: [proposal] How to do logging from the command line (was: Re: Logging of exception.)
OK, forget it. I'm obviously worse at explaining things than I thought. I don't have the time to chew this through. It should have been quick and painless, but obviously it isn't. Hopefully, someone else has a better solution. I'm sorry for wasting your time writing this answer. Back to my JNI wrapper for FOP... Jeremias Maerki
Re: [proposal] How to do logging from the command line (was: Re: Logging of exception.)
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > Hi Finn, > > I took a look at it and I must say that I'm a bit > confused, too. > > Anyway, I have a proposal to make. I would expect a > command-line > application to work like any other C-program such as > "grep", "svn", "ls" or > whatever. That means you don't get any "[INFO]" > before each line, but > you can define the log level (normally "quiet", > "normal" and "verbose") > through command line switches. That'll work for most > CLI-users. > Errr, we're using Commons-Logging now. I don't think we should wrap it. Perhaps we should switch to System.out/.err for Command Line use though, a la Xalan. > That would probably mean > not to use > SimpleLog but to provide a special implementation > for command-line use. SimpleLog is out the window with 1.4 JDK--C-L uses Java Logging by default there, which IIRC, doesn't have those messages, or if it does can be configured by the underlying implementation. No architectural decisions IMO should be based on the behavior of SimpleLog--it's yesterday's news. Remember, Xalan, Xerces, and Batik don't use logging, and I see FOP moving in this direction--logging less and less over time. > For those who know about C-L and want to do some > special logging we > could have a command line switch that disables our > special logger setup. > They can fully control C-L from outside. > We don't do much for the user community in separating them from C-L (a highly useful skill, its not like we're forcing them to learn Icelandic), and having them learn another nonportable logger implementation instead. Ideally, if there's problems with C-L complexity the solution should be to go to C-L team and complain on the user's lists or send Bugzilla reports to get those problems fixed. Not for each of the 90 or so open-source systems that use C-L to be wrapping it instead. Glen
[proposal] How to do logging from the command line (was: Re: Logging of exception.)
Hi Finn, I took a look at it and I must say that I'm a bit confused, too. Anyway, I have a proposal to make. I would expect a command-line application to work like any other C-program such as "grep", "svn", "ls" or whatever. That means you don't get any "[INFO]" before each line, but you can define the log level (normally "quiet", "normal" and "verbose") through command line switches. That'll work for most CLI-users. Since the Fop class is the one to control the whole application it (or rather the CommandLineOptions class) can also set up C-L to behave exactly as explained above. That would probably mean not to use SimpleLog but to provide a special implementation for command-line use. At any rate, I don't agree with the way that SimpleLog is implemented. Informational messages should go to System.out, errors to System.err. Logging prefixes should be disabled. I've had to do the same for Avalon Logging in Barcode4J [1] and I'm very pleased with the result. Using this I was able to implement the Barcode4J CLI in a way that the generated barcode could be output to System.out which may also be desirable for certain people. You could even modify the whole thing in way that you could implement FOP as a filter application getting the input through System.in and sending the output to System.out, giving error messages through System.err. For those who know about C-L and want to do some special logging we could have a command line switch that disables our special logger setup. They can fully control C-L from outside. For the cases where FOP is used embedded in a bigger software, FOP shouldn't manipulate anything in C-L, it's simply the developer's job to set up C-L from outside. WDYT? PS: One issue I found is that there are still several System.out/err everywhere in the source code. These lines should be rewritten to use C-L. [1] http://cvs.sourceforge.net/viewcvs.py/barcode4j/barcode4j/src/java/org/krysalis/barcode4j/cli/AdvancedConsoleLogger.java?rev=1.2&view=auto On 08.09.2004 23:15:50 Finn Bock wrote: > Hi, > > I didn't follow the discussion in the spring about command line -d and > commons-logging so I'm likely missing some important pieces, but I'm a > bit confused about the result. > > If I attempt to render a fatally corrupt input fo file like: > > > > , I get the expected SAXParseException message on the console and the > "Turn on debugging for more information" line. > > When I turn on debugging, then the full exception is printed directly on > the console (without using C-L!) and no information about the exception > is sendt to C-L. > > So the C-L debug level directly controls output to System.err. That > makes very little sense to me. > > At the very least the exception should be logged to C-L, right? > > I would also guess that any additional System.err output should be > controlled separately from C-L, with a -d option. > > regards, > finn Jeremias Maerki
Logging of exception.
Hi, I didn't follow the discussion in the spring about command line -d and commons-logging so I'm likely missing some important pieces, but I'm a bit confused about the result. If I attempt to render a fatally corrupt input fo file like: , I get the expected SAXParseException message on the console and the "Turn on debugging for more information" line. When I turn on debugging, then the full exception is printed directly on the console (without using C-L!) and no information about the exception is sendt to C-L. So the C-L debug level directly controls output to System.err. That makes very little sense to me. At the very least the exception should be logged to C-L, right? I would also guess that any additional System.err output should be controlled separately from C-L, with a -d option. regards, finn
