On 8/31/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> [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?
I don't think it's a particularly big job putting in resource bundles but
I'll go with the majority decision if people are concerned about getting if
done in time. We will have to do it at some stage.
> 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?
Only if you don;t specify a bundle for the extension . So the rule shoyuld
be you always provide an bundle for an extension. I was just making the
point that we don't absolutely need a bundle for each modules unless it's
loaded as an extension. However it may be simpler just to say 1 per module
and then it's easier to remember.
> 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.
Ok , well let's see what people think. As you say not hugely difficult to
go round and hoover up all the messages and convert into bundles.
> 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?
The usual logging configuration, what we want our default logging level to
be on a module by module bases, what handlers to use, configuration of the
handlers e.g. if it's a file handler where to put the file and what to call
it. etc.
I'm using the IBM JDK and that doesn't seem to come with a default
logging.properties file. We could go with hardcoded defaults but as soon as
you want to change something it's problematic. We could ask people to drop
one into jdk/lib but that would be active for any other java apps they use.
Do you know an easy way round this?
--
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
