HyperSQL Database Engine (HSQLDB)

System property name changed to hsqldb.reconfig_logging to be consistent
with other system properties that we use. Rev. 4128.

excellent, works great, thanks!

Suggested System Property fix applied with svn rev. 4120.

Please test by setting system property 'org.hsqldb.reconfigLogging' to the
string value "false".

Rev. 4119 included the instance-specific category prefix enhancement as
suggested here.

I understood. The 'ole static singleton problem.

WRT configuration, the goal of FrameworkLogger is to set up useful default
logging if the user has customized neither log4j nor JUL, and to leave
things alone otherwise. I do not want to require a runtime setting to
trigger our default setup because most users would not know of it and would
end up with terrible JUL defaults or Log4j aborting with stderr messages.
The difficulty is that it is with detecting if an app has programmatically
configured JUL, especially considering that it may not be a Sun JVM.

my problem with reconfigure method is that it resets logging configuration
which is not its own, and that it is unavoidably called in the static{}
block in the beginning of the FrameworkLogger class.

as an example: imagine if my application loaded 3 different libraries
which all had similar static blocks. the JUL logging configuration would
be a mess, would be inconsistent due to classloading order, and would be
"incorrect" for all the libraries except the last one loaded.

Re Log4j, their hierarchy uses a Hashtable, and they provide no means to
remove elements. I guess all I can do is release the links from our
Framework. if Log4j ever adds support for freeing Loggers, we'll
accommodate.

I think both the code in the reconfigure method and the name itself make it
clear that it is designed so that it can be called multiple times and it
will "reconfigure" logging each time it is called. Depending on LogManager
isn't suitable for these goals.

Unless something else comes to light, this weekend I'll implement a new
system property as you have suggested.

okay, i see where you read the default logging config file and, if
modified, you use that configuration. what i don't understand, however, is
why you call lm.readConfiguration() again? the LogManager does that on
startup, so what use does that serve?

setting "java.util.logging.config.file" will not work for us. we don't
completely subvert the existing logging configuration, we just add extra
loggers/handlers on top of it. and, regardless, any call to
readConfiguration _resets_ any existing loggers, which clears out any
configuration we have done post-startup.

James: Could I get you run a test for me? With the distributed
FrameworkLogger restored, could you set system property
java.util.logging.config.file to the path to any file (even an empty one)
in your JDK invocation, and see if things work as you want? Please don't
set the sys property in code because that would introduce uncertainty as to
whether the variable gets set before the framework reads it.

The whole point of logging frameworks, as you understand it, is
accommodated by our implementation-- just not for
programmatically-configured hierarchies. You could configure JUL with a
runtime properties file and it would be honored. The great majority of
applications do want to configure their logging declaratively. But there
is nothing wrong with wanting to do it programmatically, and programmatic
configuration lets you get around some of some of JUL's several
embarrassing limitations (compared to Log4j, for example). My goal here is
to accommodate that use case.

I like your suggestion of having user specify whether to manage logging
hierarchy. Less complex and probably safer than trying to figure out what
to do algorithmically.

Great idea for a separate name space for the instance specifiers. I'll add
that.

the whole point of logging frameworks (as i understand it), is that the
library grabs loggers and logs information. the user of the final
application is responsible for configuring log levels for the different
components as they see fit. that's why it seems odd to me that hsqldb is
completely recconfiguring the JUL logging infrastructure.

i can understand that hsqldb has to run in a few different "modes", and in
the "server mode" it may make sense to take over the application log
configuration (even in this mode, you could still provide the JUL
properties file and say "please use this file when running the hsqldb
server"). however, in "embedded/client mode" it does not make sense at
all.

currently, i've just commented out the whole block in reconfigure() which
mucks with the JUL LogManager and it works just fine. that's why i
suggested a system property to control this behavior. something like
"hsqldb.dontTouchMyLogConfig=true" which, when enabled, skips the whole
block in reconfigure() which touches the JUL LogManager.

one related suggestion. when creating loggers for the JUL logging
subsystem, it would be nice if the database specific loggers were nested
under the "hsqldb" hierarchy (possibly in their own subgroup, like
"hsqldb.db"). currently, they are created using just "unique_db_name",
which puts them in the "root" of the logging hierarchy. if they were
instead named "hsqldb.db.unique_db_name", it would make it easier for an
app developer to control logging.

It's due to the complex discovery mechanisms that have to be accommodated.
See the comments in method FrameworkLogger.reconfigure(). As noted there
and as you have noted, it is a real problem for apps that programmatically
configure JUL.

Maybe it would be better to detect app logging customization, and if that
is detected, then do no hierarchy management whatsoever and just pass
through to the back end log() methods. The app would assume the
responsibility to set up a reasonable default appender and set up
instance-specific routing and whatever else FrameworkLogger does (I will
have to review).

Alternative suggestions welcome.

Note, i'm using hsqldb-2.1.0-rc4.