Hi! Just a general observation as someone who took a pretty deep look into log4j (1 and 2) and other logger frameworks.
i18n logging is *piep* - it's really not worth it! We really need to distinguish technical logging from presenting 'messages' to the user. Logging should be for the log only, and NEVER make it to the face of an end user. And as such, only a technician will need to deal with it. I suggest to ONLY log in english, because then it's much easier to look up the problem on the internet. Imaging getting a Hungarian log message on our list. Does anybody here know what that text would actually mean? NOPE. And also our Hungarian friends would also not be able to search for their problems on the internet, because the chance that they find the Hungarian error text is almost null. Au contraire for always logging in English: it will be easy for us and easy for the guy/gal having the problem to search for a solution. So all the i18n stuff for _logging_ is really unnecessary. Of course the idea looks generally good for our messaging module. I really liked the CODI messaging module which could create JSF messages on the fly. Your idea with the typesafe approach could fit nicely for that - and it looks easy to provide tool support for creating the resource bundles. That is also one thing I like to address on the long run: tool support for DeltaSpike resource bundles. Currently pretty much every Java Resource bundle will a.) pretty quickly run out of sync for the different languages (the order must be preserved manually) b.) pretty quickly will contain unused resource keys. If we can solve this problem, I'd be more than happy. But again: this is a messaging issue and does NOT affect logging at all! LieGrue, strub ----- Original Message ----- > From: Ken Finnigan <[email protected]> > To: [email protected] > Cc: > Sent: Monday, January 23, 2012 4:22 AM > Subject: [DISCUSS] Logging > > All, > > As we approach a 0.1 release of DeltaSpike, congratulations to everyone on > the good work so far, I feel it's a good time to begin discussing how we > want to handle logging within DeltaSpike. I certainly don't expect this > discussion to result in code for 0.1, but the earlier we begin this > discussion, then it increases the likelihood of it being ready for 0.2 > > Having been heavily involved in the logging work for Solder, I know the > pain that can be experienced in not getting it right, and also how long it > can take to get right. > > I see that there are several goals that we want for logging in DeltaSpike: > > 1. Make it simple for both extension writers and end users. If it's too > difficult to implement, use or even get right, then we'll frustrate and > alienate developers. > 2. It must perform. We don't want to introduce large overhead to > logging. > 3. There should be an option to allow/provide type safe logging. [1] > 4. An end user should be able to have DeltaSpike log against whichever > logging library they want to utilize in their application. We can > certainly support a specific framework as a default, but it's important > to > allow a developer to have the same control over how DeltaSpike is logged as > their own application. > > Thoughts? > > Regards > > Ken Finnigan > > > [1] An example of type safe logging, from Solder, is to define an interface > such as: > > @MessageLogger > public interface BirdLogger { > @Log > @Message("Spotted %s Hawks") > void logHawksSpotted(int number); > > @Log > @Message("Spotted %s Owls") > void logOwlsSpotted(int number); > > @Log > @Message("Spotted %s Bald Eagles") > void logBaldEaglesSpotted(int number); > } > > and then create properties files for each language that you want to support > for these log messages. For instance, if the interface existed in the > org.deltaspike.logging package, then you would create > org.deltaspike.logging.BirdLogger.i18n_fr.properties containing names > matching the methods on the above interface, and values representing > localized versions of the String within @Message. > > Finally, a compile time annotation processor would generate concrete > classes for each interface and localized version. In the above example you > would end up with BirdLogger.class and BirdLogger_fr.class > > To use the logger that was generated, you then simply do something like: > @Inject > private BirdLogger logger; > > public void generateLogMessage() { > logger.logBaldEaglesSpotted(2); > } >
