At 14:33 07.03.2001 -0600, Johnson, Clay wrote:
>> -----Original Message-----
>> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
>> Sent: Wednesday, March 07, 2001 8:38 AM
>> To: LOG4J Users Mailing List
>> Subject: Re: backend l10n
>>
>>
>> At 11:13 06.03.2001 -0600, Johnson, Clay wrote:
>> >Folks,
>> >
>> >I have a requirement to defer l10n processing to appenders,
>> rather than at
>> >the publisher of the log event, in order that different appenders may
>> >localize the same event according to different locales.
>> Since the l10n
>> >methods in Category rely on preregistered ResourceBundles,
>> that doesn't
>> >work. Furthermore, with only a cursory look at the
>> internals, it appears
>> >log4j converts the message Object to a String to construct a
>> LoggingEvent
>> >*prior* to distributing that to all appenders. If that is
>> true, I worry
>> >whether my requirement can be met without substantial
>> >modification/extension.
>>
>> Starting with version 1.1, log4j allows layouts/appenders to
>> access the raw message object. See getMessage() in
>> org.apache.log4j.spi.LoggingEvent. So you can write an
>> Appender that will convert a message string in a local
>> specific manner.
>
>Great, that solves the deserialization step. (BTW, comparing the 1.1 and
>1.0.4 API for LoggingEvent, I notice a method was dropped without
>deprecation notice. Was this deliberate, and what is apache policy?)
Which method is this? Methods should be deprecated before being removed.
>> Before going on, it is useful to consider the l7dlog methods
>> in the Category class:
>>
>> // Log a localized and parameterized message:
>> void l7dlog(Priority priority, String key, Object[] params,
>> Throwable t)
>>
>> // Log a localized message:
>> void l7dlog(Priority priority, String key, Throwable t)
>>
>> These methods consider the second parameter as a key in a
>> ResourceBundle and not as a string message. The LoggingEvent
>> class only considers message objects not message keys nor
>> parameters to the localized conversion.
>
>Yes, that distinction is evident, and it is one of my concerns moving
>forward in 1.0.4; unless I am to subclass Category, LoggingEvent, and
>Appender to accomplish this, I had planned to tunnel my key/args through the
>message (i.e. not l7d) methods, and I was considering how to circumvent
>serialization.
>
>However, now I see in 1.1 Category.forcedlog() no longer serializes, but
>constructs a LoggingEvent with the message object. In fact, serialization
>is now lazy in LoggingEvent.getRenderedMessage(). If, as I hope/suspect,
>that is called by the Appender during layout, than it may turn out that
>ObjectRenderer is the answer after all (in 1.1); if I subclass and register
>an ObjectRenderer to localize my Object, would this bootstrap into the
>existing Appender classes as I imagine?
It is layouts that call LoggingEvent.getRenderedMessage() not appender, although this
is a minor detail. You could indeed register an ObjectRenderer to localize a message.
There are two problems with this approach:
1) You must create a new type (class) that carries the localization key, and parameter
objects. This is probably somewhat inconvenient.
2) There can only be one ObjectRenderer per class. So your original requirement to
have Appender1 localize in say french, and Appender2 localize messages in Spanish
would not be possible. Or?
>I'll check the source, awaiting.
>
>> It is clear that LoggingEvent must be extended, possibly by
>> sub-classing, to include a key and parameters (of type Object
>> array) to cater for the localized logging case.
>
>Not unless you want to adopt this feature ("appender localization"?)
>officially.
The problem of appender localization is closely related to the problem of localization
at the source versus remote localization. Solving the former problem should solve the
latter. (Currently, log4j only supports localization at the source.)
>If not, provided my previous assumptions are corrent, users like me can
>create a class encapsulating the key and replaceables, pass this as an
>opaque Object through the existing Category log methods, register an
>ObjectRenderer to localize/render that class, and voila. Right?
>
>> The other problem is to choose method signatures that allow
>> both message logging and localized logging. Any suggestions? Ceki
>
>On the other hand, if you want to adopt this feature, I would be interested
>to discuss possible API further; in the event future releases of log4j do
>this, I would like to be able to anticipate the architecture so I can switch
>to it when/if.
>
>Perhaps this topic should move to the dev list, but if so, let me know,
>because I'm not subscribed there.
>
>And thank you for your prompt attention to me and others,
>
>Clay
Yes, moving the discussion to log4j-dev is probably wiser. Ceki
I hope to see you at my ApacheCon 2001 presentation
entitled "Log4j, A Logging Package for Java".
See http://ApacheCon.Com/2001/US/ for more details.
----
Ceki Gülcü Web: http://qos.ch
av. de Rumine 5 email: [EMAIL PROTECTED] (preferred)
CH-1005 Lausanne [EMAIL PROTECTED]
Switzerland Tel: ++41 21 351 23 15
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
