At 08:08 03.07.2001 -0700, you wrote:
>Hi Pavel,
>
>I agree that localization resource bundles are important. In fact, the
>only thing I liked better about jlog (called jras back then) was that it
>was designed primarily to use localization bundles. Methods where the
>string was hard-coded were provided merely as a convenience feature for
>those "special cases". Unfortunately, this benefit seems mutually
>exclusive with some log4j benefits that I like.
>
>Actually, jlog (this is one year old knowledge of jlog I'm working with)
>divided logging into trace logging and event logging. The idea was that
>trace log output was designed to be read by the developer while event log
>output was designed to be read by the final product's user. So trace log
>output was hard coded (no localization) while event logging was localized.
>Localized logging is a PITA, but if you have the discipline to use it, it
>yields several advantages on larger scale projects.
>
>The appserver example packages uses a msg resource bundle in its
>configuration. But in that case, I made the resource bundle a property of
>the category factory, not the category itself. This has worked fine for
>all my projects, but others might want to customize the bundle on a per
>category basis.
It is true that there is no configuration support for bundles.
>Ceki, I'm not sure what you meant by "irreversible." Do you mean that if
>someone configures a category with a certain resource bundle they couldn't
>unconfigure it later? I also don't understand the comment about
>"completely changing the way log4j is used." Log4j already allows one to
>use resource bundles. How would this change anything (for those that don't
>use it)?
I afraid we are using the term localization differently. As I understand it, Pavel
wanted to have categories get their name from the class they were defined
automatically.
As in
class X {
Category cat = Category.getInstance();
}
instead of the current
class X {
Category cat = Category.getInstance(X.class);
}
Changing client code to use:
class X {
Category cat = Category.getInstance();
}
is "irreversible" in the sense that it is not a configuration parameter that one flip
in order to revert to the old Category.getInstance(X.class) type code.
At least this is how I understand it. Regards, Ceki
>- Paul
>
>Paul Glezen
>IT Specialist
>Software Services for WebSphere
>818 539 3321
>
>
>Pavel Muhataev <[EMAIL PROTECTED]> on 07/03/2001 02:57:21 AM
>
>Please respond to "LOG4J Developers Mailing List"
> <[EMAIL PROTECTED]>
>
>To: LOG4J Developers Mailing List <[EMAIL PROTECTED]>
>cc:
>Subject: RE: Localization configuration
>
>
>
>Hi,
>
>In log4j there is capability of using localized messages. I use this
>capability for defining log messages text due to message ID. Localization
>can be configured only at run-time. But why there is no capability of
>defining log messages bundles with configuration files?
>
>I think, that configuration files are also irreversible, so we can use them
>to configure category's resource bundle.
>
>Best regards, Paul Mykhataew,
>ICQ #33733798
>
>-----Original Message-----
>From: Ceki Gulcu [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, July 03, 2001 13:55
>To: LOG4J Developers Mailing List
>Subject: Re: Localization configuration
>
>
>At 13:31 03.07.2001 +0400, you wrote:
>>Hi,
>>
>>How about adding capability of localization configuration via
>configuration
>>files?
>
>"Localization configuration" is not a configuration option. It is
>irreversible as far as things are irreversible in software. It also
>completely changes the way the log4j package is used and perceived by
>users.
>Am I correct? Regards, Ceki
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
