+1 for Gerhard Petracek On Mon, Jan 23, 2012 at 12:03 PM, Gerhard Petracek < [email protected]> wrote:
> @logging: > i agree with mark > > @resource bundles in general: > that needs to be a separated thread. > > regards, > gerhard > > > > 2012/1/23 Mark Struberg <[email protected]> > > > 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); > > > } > > > > > > -- Mehdi Heidarzadeh Ardalani Independent JEE Counselor, Developer and Trainer. http://www.TheBigJavaBlog.com
