Logging of exception.

[Finn Bock <bc...@worldonline.dk>]

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:

     <fo:block/>

, 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

Re: [proposal] How to do logging from the command line

[Finn Bock <bc...@worldonline.dk>]

[Jeremias]

> 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?

I like it. It will get consistent results for command line users without 
  them (practicly) ever having to do any logging configuration.

I have added a patch with an implementation of your proposal. Feel free 
to point out any mistakes that I have made.

Glen, I'm a bit confused about your objections. I don't think they apply 
to Jeremias' proposal at all.

- SimpleLog plays *no* part in this.
- There is no wrapping of c-l in any way, we just supply own very
   simple specialized logging implementation.
- Users can still use other c-l loggers (jdk14, log4j, etc.) by
   setting LOGCHOICE in fop.bat

regards,
finn

Re: [proposal] How to do logging from the command line (was: Re: Logging of exception.)

[Glen Mazza <gr...@yahoo.com>]

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 <de...@greenmail.ch> 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.)

[Jeremias Maerki <de...@greenmail.ch>]

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.)

[Glen Mazza <gr...@yahoo.com>]

--- Jeremias Maerki <de...@greenmail.ch> 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.)

[Jeremias Maerki <de...@greenmail.ch>]

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:
> 
>      <fo:block/>
> 
> , 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