> -----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?)
> 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?
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.
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
>
>
> ---------------------------------------------------------------------
> 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]
