[snip]
Simon Laws wrote:
Ok, so we know there is no generally acceptable logging interface. Has
been proved time and time again. All we can hope to do is use something that
suits us and doesn't mess up anyone who wants to embed our code.
I'm perfectly happy to +1 JDK logging. However without some wrappers to do
it for us we need to define the ground rules for how we use it.
So, in line with what I believe is common practice, how about these...
End user readable information is expected to be recorded against the
following levels
SEVERE
WARNING
INFO
CONFIG
The following levels are tracing levels and are assumed to be developer
readable only
FINE
FINER
FINEST
+1 from me
Loggers will be initialized against the class name to which they relate, and
a resource bundle for the package/or module.
How about leaving the resource-bundle part out for 1.0 and do a pass to
externalize messages later?
private static final Logger Log = Logger.getLogger(
SomeTuscanyClassB.class.getName(), "tuscany-?-messages");
We can define some global o.a.t.s loggers if we don't want to have to make
bundles for all of the non-extension modules, e.g.
private static final Logger Log = Logger.getLogger("org.apache.tuscany.sca,
"tuscany-messages");
Hmm, wouldn't that require changes in the module containing the "global"
module when an extension wants to change a message?
Log statements for user readable messages will take the following form, for
example,
Log.log(Level.INFO,
"MESSAGE1");
String componentName = "Some component";
Log.log(Level.INFO,
"MESSAGE2", // message id
componentName); // parameter
Integer params[] = {8, 9, 4};
Log.log(Level.INFO,
"MESSAGE3", // message id
params); // parameter
Exception ex = new IllegalStateException("TEST_MESSAGE");
Log.log(Level.INFO,
"MESSAGE4", // message id
ex); // parameter
These messages will be localized against a message bundle from the classpath
based on the configuration of the Logger (or the Logger's parent), for
example, tuscany-messages.properties, tuscany-messages_en.properties etc.
MESSAGE1 = This is a test message with no params
MESSAGE2 = This is a test message with a string param {0}
MESSAGE3 = This is a test message with numbers {0}, {1}, {2}
MESSAGE4 = This is a test message with exception
+1 for all that, except that again I'll be more comfortable to leave
externalization to later after 1.0.
Which can of course be provided on an extension by extension basis if
required and if specified when the logger is created.
Developer readable messages are assumed not to be localized and so can be
output using the Logger convenience methods.
We won't use log.entering and log exiting. This level of tracing will be
provided via AspectJ injection.
+1
I'm assuming we don't want our logging properties to have to live in
jdk/lib/logging properties so we need an extensible/replaceable way to
initialize logging. e.g.
InputStream logConfigStream = Thread.currentThread
().getContextClassLoader().getResourceAsStream("tuscany-logging.properties
");
LogManager.getLogManager().readConfiguration(logConfigStream);
+ any other logging configuration that we need
Anyone have a good idea where to put this. It should go close to the start
of our domain/node implementation but would be good if it's replaceable. So
we could do with a new logging extension type that is one of the first
things that gets loaded.
Simon
What would be put in specific logging properties?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
