On Fri, Jan 31, 2014 at 2:38 PM, Ralph Goers <[email protected]>wrote:
> Did you look at how we emulate the localization in the Log4j 1.x bridge? > I wrote a LocalizedMessage to handle that. Personally, I don’t like the > class because it was implemented solely to make Log4j 1.x work more or less > the way it always did. > > We people talk to me about localization I would tell them that if that is > what you want you should be logging Messages that contain a message number > and substitution data. The localization should happen in the application > that is reading the log file, not writing it. However, I seem to have a > hard time convincing people to do it that way. > > In any case, if you really want to do it that way then IMO the way to do > it would be to use a ResourceBundleMessage or something similar. > As part of this porting exercise, I am building Loggers with a LocalizedMessagFactory for given resource bundles. So that's fine: LogManager.getLogger(Foo.class, new LocalizedMessagFactory(baseName)); It's a little funky in LocalizedMessagFactory and LocalizedMessag that we track both the RB base name and the RB itself but it looks like this is a requirement to get Serialization to work, which I am not convinced it does. If I create a LocalizedMessagFactory with a baseName, then the LocalizedMessag is serialized with the baseName and no RB. Fine. But if I only build the LocalizedMessagFactory with an RB then the message object cannot be deserialized properly because the RB is transient. So there's something not quite right there, at least at first glance. WRT localization and ints vs. messages: our users would not know what to do with logs that had numbers instead of messages in them. Unless Log4j provides such a viewer I would not even go there. Even if it did, it sure makes it more of a pain to deal with. Right now I can download a user's log from our JIRA and look at it on my phone. I can't imagine that we'd provide mobile viewers. Then there would be XSL but I'd need to get that running on the phone too... Basically text files are fine. It could be an option of course, where the in the API message is an enum or an int. Good chat... Gary > Ralph > > On Jan 31, 2014, at 7:16 AM, Gary Gregory <[email protected]> wrote: > > On Fri, Jan 31, 2014 at 10:08 AM, Remko Popma <[email protected]>wrote: > >> Hm... I should have looked it up sooner... :-( >> > > We're all sync'd up now :) > > Gary > > >> >> >> On Sat, Feb 1, 2014 at 12:07 AM, Gary Gregory <[email protected]>wrote: >> >>> On Fri, Jan 31, 2014 at 3:06 AM, Remko Popma <[email protected]>wrote: >>> >>>> I should have looked this up... >>>> l7dlog() methods replace the user-supplied key by its localized version >>>> from the resource bundle. >>>> >>>> So this is about the log message text, not the level names. Please >>>> disregard my previous email. >>>> >>> >>> Now I see this :) ah! Good digging Remko! >>> >>> Gary >>> >>> >>>> >>>> One of my colleagues raised an interesting point: We have some systems >>>> where the log files are tailed and monitored, and alerts are raised for >>>> certain keywords. For those systems it is important that the format doesn't >>>> change when upgrading. >>> >>> >>>> That may actually be a good argument in favor of supporting >>>> localization in log4j 2.0... >>>> >>> >>>> >>>> >>>> >>>> On Friday, January 31, 2014, Remko Popma <[email protected]> wrote: >>>> >>>>> I asked a number of Japanese and Chinese colleagues, but nobody seemed >>>>> to want the level names translated in the log output. They were all >>>>> happy with the English names. About half advised against translating, half >>>>> was indifferent, and one person said he wouldn't use it himself but he >>>>> thought that other people might want it. >>>>> >>>>> So maybe this is a "nice-to-have" rather than a "must-have" feature? >>>>> >>>>> On Friday, January 31, 2014, Remko Popma <[email protected]> >>>>> wrote: >>>>> >>>>>> What does the localization do? >>>>>> Is it for translating the built-in level names? >>>>>> >>>>>> >>>>>> On Friday, January 31, 2014, Gary Gregory <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> In Log4j 1 we use: >>>>>>> >>>>>>> - org.apache.log4j.Category.setResourceBundle(ResourceBundle) >>>>>>> - org.apache.log4j.Category.l7dlog(Priority, String, Object[], >>>>>>> Throwable) >>>>>>> >>>>>>> It seems v2 makes sidesteps the whole localization/i18n issue. >>>>>>> >>>>>>> What's the migration path for that? >>>>>>> >>>>>>> So we'll never play nice with some projects that require playing >>>>>>> with resource bundles. >>>>>>> >>>>>>> Should we recommend creating a Logger wrapper to hold a resource >>>>>>> bundle? I'm not sure what else we can do... we could provide it... >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Gary >>>>>>> -- >>>>>>> E-Mail: [email protected] | [email protected] >>>>>>> Java Persistence with Hibernate, Second >>>>>>> Edition<http://www.manning.com/bauer3/> >>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>>>>>> Spring Batch in Action <http://www.manning.com/templier/> >>>>>>> Blog: http://garygregory.wordpress.com >>>>>>> Home: http://garygregory.com/ >>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>> >>>>>> >>> >>> >>> -- >>> E-Mail: [email protected] | [email protected] >>> Java Persistence with Hibernate, Second >>> Edition<http://www.manning.com/bauer3/> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>> Spring Batch in Action <http://www.manning.com/templier/> >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >> >> > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
