Hello, i think slf4j is a better alternative for logging compare to commons-logging. I don't like to start a slf4j vs commons-logging battle.
Just ask google. I will change the tobago logging to slf4j. Regards Bernd Mario Ivankovits schrieb: > hi, > > basically yes, thats what I thought. > Not sure if registering resource bundles is the way to go as this leads to > duplicate/overridden keys then. Think what happens if you have 80+ libraries > everyone registering a resource bundle. > > Thats why I thought it should be the responsibility of the app. > > Hmmm ... What about extendig the log api with something like > > log.warn(textKeyMapper, string key, object ... args) > or even better > Log log = LogFactory.getLog(textKeyMapper, clazz) > > the textKeyMapper (or whatever name) is a simple interface like > > string getLanguageText(string key) > > or renaming it to TextFormatter with > > string formatText(string key, object ... args) > > The app then could use whatever it would like to to translate the key. > Not everyone uses resourcebundles. > > If registering such a thing globally means you also have to deal with a scope > (regexp against class-name ?) where the resource bundle should be applied. > This to avoid the thing said in the first paragraph in this mail. > > Reg cl: now that most classloader issues have been fixed you'd render it end > of live?!? Open-Sourceish, I know ;-) > I still dont get it ... and do not reach a pc till afternoon. But all of the > above could make it into cl too. I wont reiterate what I've wrote already. > I'll abstain from a negative vote ... You probably know better and I am > flexible enough to setup our app as required. Hopefully our users will think > the same :-) > > > Mario > > -----Original Message----- > From: simon <[EMAIL PROTECTED]> > Date: Sunday, Dez 16, 2007 9:17 am > Subject: Re: [commons] What Logger ? > To: Reply- "MyFaces Development" <[email protected]>To: MyFaces > Development <[email protected]> > > Hi Mario, >> You mean a myfaces-commons-logging module, that the following depend on? >> * myfaces-commons-* >> * myfaces-core >> * myfaces-trinidad >> >> The problem again is that each of those has its own resource bundle for its >> messages, and that there would need to be some mechanism for it to inform >> the myfaces-commons-logging module about them. >> >> It seems that it might be easier to provide patches to slf4j to register >> resource bundles for specific category strings, eg >> >> org.slf4j.LoggerFactory.registerResource( >> String category, >> String bundleName); >> >> But then the question is how such a call would be triggered. Maybe a static >> block on an important class in every library could be used to >> trigger that..seems sane at first thought, although logging is so >> surprisingly tricky I am hesitant to say that any new feature is >> actually possible. >> >> Not sure how the SLF4J project would see that kind of patch. I'll ask >> though.. >> >> The same kind of functionality could be added to commons-logging too I >> guess. But I had hoped commons-logging was at the end of its development >> life.. >> >> Regards, >> >> Simon >> >> On Sat, 2007-12-15 at 20:07 +0100, Mario Ivankovits wrote: >> this sounds like yet another complexity. >> >> I18n can be solved by a custom app layer even easier, no? >> >> So this would mean we should go your custom myfaces logger wrapper. I would >> not complain if commons depend on it, I think. >> >> >> Mario >> >> -----Original Message----- >> From: simon <[EMAIL PROTECTED]> >> Date: Saturday, Dez 15, 2007 8:00 pm >> Subject: Re: [commons] What Logger ? >> To: Reply- "MyFaces Development" <[email protected]>To: MyFaces >> Development <[email protected]> >> >> The issue is that Trinidad (ADF faces) has always emitted >>> internationalised log messages, by using its own logging implementation. >>> >>> But commons-logging does not offer any help for that. If code wants to emit >>> a log message that can be internationalised, it looks like this: >>> >>> if (log.isDebugEnabled()) { >>> String msg = TrinidadMsgFormatter.format("SomeMsgKey", arg1, arg2); >>> log.debug(msg); >>> } >>> >>> This is certainly inconvenient. >>> >>> The slf4j equivalent looks like this: >>> log.debug("SomeMsgKey", arg1, arg2); >>> which at initial glance seems nicer. >>> >>> However there are a number of gotchas. The most important is how the >>> resources are found to map (key, args) to a sensible message. >>> >>> If the underlying logging impl > >
