Hi,
In addition to Dan's comments below - it may be useful to know the Bus ID etc but in cases where you are generally looking for this information it still won't be enough and you still will have to hand craft the information into the message anyway and this can be done quite easily. In using Lars example : It can be pretty neat when you see an error message and you can identify that it was generated from the "geronimoStandardORB.connectionHandlerThreadPool" logger. With slf4j your only info would typically be "o.a.yoko.orb.ThreadPool" that might as well belong to a second ORB that has been instantiated by user code. You still don't have access say for example if you wanted to know the ThreadPoolSize. Another example: Say if you have a http transport server failing - the information that you really need is the URL its on or the port and finding its instance of the httpserver doesn't really give you enough information - so when coding this up - you really need to add this information into the message for the log. As regards getting the wrong language - this won't happen because this is actually based on the locale - The Logic ensures it picks the most specific one to the more generic one. So in the case if you are in germany you will never get thai etc. The way celtix uses the java util logging is simple and the extra information of knowing the instance names can be added to the message. Having to pass Loggers around is not a good idea. Cheers, Edell. Note from the Class ResourceBundle API: Resource bundles contain locale-specific objects. When your program needs a locale-specific resource, a String for example, your program can load it from the resource bundle that is appropriate for the current user's locale. In this way, you can write program code that is largely independent of the user's locale isolating most, if not all, of the locale-specific information in resource bundles. Resource bundles belong to families whose members share a common base name, but whose names also have additional components that identify their locales. For example, the base name of a family of resource bundles might be "MyResources". The family should have a default resource bundle which simply has the same name as its family - "MyResources" - and will be used as the bundle of last resort if a specific locale is not supported. The family can then provide as many locale-specific members as needed, for example a German one named "MyResources_de". Each resource bundle in a family contains the same items, but the items have been translated for the locale represented by that resource bundle. For example, both "MyResources" and "MyResources_de" may have a String that's used on a button for canceling operations. In "MyResources" the String may contain "Cancel" and in "MyResources_de" it may contain "Abbrechen". If there are different resources for different countries, you can make specializations: for example, "MyResources_de_CH" contains objects for the German language (de) in Switzerland (CH). If you want to only modify some of the resources in the specialization, you can do so. -----Original Message----- From: Kulp, John Daniel Sent: 07 April 2006 00:31 To: yoko-dev@incubator.apache.org Cc: Lars Kühne Subject: Re: coding standard and logging On Thursday 06 April 2006 18:12, Lars Kühne wrote: > Daniel Kulp wrote: > >Neither of those two support i18n capabilities in the logger. Thus, > > you would need to i18n the log messages ahead of time. One of the > > nice things about JDK logging is that they can be created with the > >resource bundles that contain the i18n messages. > > I'm not sure this is really desirable. I need to be able to at least > control the locale of the generated output. I don't see how j.u.l > allows that, it seems to always use the default locale. > > I work for an independent software vendor, and our applications are > installed globally. To support our products we need their logfiles in > a language that our developers understand (i.e. english or german). > Receiving logfiles that contain error messages in Czech, Thai, > Norwegian, etc. is not a viable option for us. The policy we have for Celtix (although not followed as well as it should be) is that stuff logged with SEVERE or WARNING should always be localized. The basic reason is that this is stuff that an admin of the application probably needs to know while trying to figure out what went wrong, why the application didn't start, servlet didn't deploy, etc.... Example: FileNotFound type things or "Cannot connect to host" things that the admin shouldn't have to contact us to fix. Stuff in INFO and lower are usually only useful for us or someone VERY familiar with the code. Thus, we don't normally localize those. The good thing is the j.u.l stuff supports that and whatever you guys choose should as well. It's important that users have the ability to localize the errors so their admins can diagnose stuff without having to contact us. Anyway, Celtix ONLY uses j.u.l based logging. That said, the ability to have a "root" logger based on the current Bus ID like Lars described definitely would be useful and makes sense, although that could easily be done with the j.u.l based logging as well. (except our checkstyle rules would complain, but that's a different issue) Enjoy! -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
