Bug #4761


Interaction of Configuration.setLogger() and Configuration.setStandardErrorOutput()

Added by Michael Kay almost 2 years ago. Updated almost 2 years ago.

Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
10, trunk
Fix Committed on Branch:
10, trunk
Fixed in Maintenance Release:


This is a spin-off of bug #4760

Configuration.setLogger() and Configuration.setStandardErrorOutput() seem to be relics of two different attempts to allow applications to redirect system messages, but neither has been well tested, and they don't play nicely together.

If I set an initializer that calls Configuration.setLogger(), then Verifier fails with an NPE trying to display the license message. The license message is sent to config.getStandardErrorOutput(), which is null if a Logger has been set. The implication is that config.setLogger() simply doesn't work. At any rate, the relationship of config.setStandardErrorOutput() and config.setLogger() is complex and poorly explained.

Tried getting around this by making the Logger extend StandardErrorLogger, but that doesn't work either, because the ErrorReporter used by the run-time Controller doesn't use the Logger registered with the Configuration.

So I'm coming to the conclusion that when running from the command line, there's no way to redirect run-time transformation warnings to a destination other than System.err.

Actions #1

Updated by Michael Kay almost 2 years ago

  • Subject changed from Interaction of Configuration.setLogger() and Configuration.setStandardOutputStream() to Interaction of Configuration.setLogger() and Configuration.setStandardErrorOutput()
  • Description updated (diff)
Actions #2

Updated by Michael Kay almost 2 years ago

Working on the Saxon 11 branch, I've started by creating a test in TransformTests that uses setLogger() with a custom logger; this provides a way of testing the content of messages that would normally go to System.err (from a simulated command line call) in a JUnit test.

This shows up the NPE when reporting the license file serial number.

I'm now going to try and ensure that all such messages go via the Logger.

Actions #3

Updated by Michael Kay almost 2 years ago

Most messages sent to System.err are now changed to go via configuration.getLogger().

Current exceptions:

  • Help messages from CommandLineOptions in response to -? go directly to System.err, because they are output before a Configuration has been created.

  • Messages from the (default) MessageEmitter (for xsl:message) go to config.getErrorOutputStream()

  • Messages that are never output except when doing internal debugging

  • Some messages for fatal error conditions where no Configuration is available

Actions #4

Updated by Michael Kay almost 2 years ago

So what to do about get/set StandardErrorOutput in Configuration?

The only place it's now used is for xsl:message output, and I'm handling that by adding a Logger.asWriter() method (with a default implementation) that supplies a Writer which writes to the Logger, and the default MessageEmitter will use this by default.

We have a write-only configuration property Feature.STANDARD_ERROR_OUTPUT_FILE which can be used (in principle) to redirect standard error output. I propose that this property, and the method Configuration.setStandardErrorOutput(), should take no action unless the Logger is a StandardLogger, in which case they should set the output destination for the standard logger.

Similarly, redefine Configuration.getStandardErrorOutput() so it returns the output destination of the Logger if it's a StandardLogger, or System.err otherwise.

Actions #7

Updated by Michael Kay almost 2 years ago

  • Category set to Diagnostics
  • Status changed from New to Resolved
  • Priority changed from Low to Normal
  • Applies to branch 10, trunk added
  • Fix Committed on Branch 10, trunk added

Fixed (as described) on the 10.x and 11 branches.

Actions #8

Updated by O'Neil Delpratt almost 2 years ago

Bug fix applied in the Saxon 10.3 maintenance release

Actions #9

Updated by O'Neil Delpratt almost 2 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 10.3 added

Please register to edit this issue

Also available in: Atom PDF