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" <dev@myfaces.apache.org>To: MyFaces
Development <dev@myfaces.apache.org>
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" <dev@myfaces.apache.org>To: MyFaces
> Development <dev@myfaces.apache.org>
>
> 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
