Thomas Tuft Muller wrote:
>
> | > I think this is an important requirement; for Category X I
> | would like to log
> | > java.lang.Integer as "Integer: " + Integer.toString( theInt ), and in
> | > category Y I would like to log it as Integer.toString( theInt ).
> | >
> | > Is it possible?
> |
> | Nope. You can't do that. An ObjectRenderer renders the same for all
> | categories.
>
> Is this a design flaw?
It's just how ObjectRenderers currently work.
>
> | If you need per-category rendering yo may have to write a Layout which
> | knows about the types of Object you log (Integers in your example), e.g.
> | a subclass of PatternLayout which recognixes custom conversion
> | characters related to your logged Objects.
>
> Sounds like a good idea.
>
> | Actually, in your example you can just use PatternLayout without any
> | extension. Basically the %m ends up being populated by calling toString
> | on your object (unless you explicitly register an ObjectRenderer for
> | Integers), so you could have a pattern "Integer: %m%n" on Category X and
> | "%m%n" on Category Y and the effect should be as you described.
>
> This imposes a category per type(?), which is not what I want. I want each
> category to have a particular formatting of an arbitrary number of types
> irrespective of what toString() for the objects returns. E.g. for
> java.net.InetAddress could possible strings be the hostname, the raw
> IP-address, or both, preferrable formatted in a flexible way. In other
> words, the stringification of an object passed to the category should be
> formatted according to other method calls on the object than toString().
I see. That sounds reasonable and like something generally useful.
The
> ObjectRenderer interface hides an implementation of how this is done for
> each type, but as I found out (and you confirmed) log4j stores renderers
> globally rather than on a per Category basis.
Right.
>
> I probably miss a few things, but it seems like the LoggingEvent doesn't
> contain the original Object (only the message i.e. the string version
> (toString() of it) passed from the application. The LoggingEvent is passed
> to each member of the list of PatternConverters from PatternLayout and ends
> up being passed to the overrided convert(LoggingEvent) method. How do I get
> hold of the original object from this point?
The original Object is in the LoggingEvent. You get it by calling
getMessage().
>
> I certainly like the idea of having rules (patterns) for conversion of
> different types, but I guess the PatternLayout class is no good for this(?)
>
> Any suggestions for a flexible design and some hints how to implement it?
Well, we're talking about something like adding conversion characters to
a PatternLayout in a way that's type specific (type here means on basis
of Class of logged Object). Three ways this might work depending on
where the knowledge of what new conversion characters mean lives:
1. In PatternLayout subclasses. This is the case I was describing
before. As you point out it's limited in that knowledge of different
types of logged Objects is hardcoded in the Layout, and you might even
have to do ugly switching on Class of logged Object.
2. In the LoggingEvent itself. In such a scheme apps might subclass
Category and LoggingEvent for different types of logged object and as
part of that they'd implement a LoggingEvent method
void format(char conversionChar, StringBuffer sbuf);
When a PatternLayout see a conversion character it doesn't know about,
it invoked this format method on the LoggingEvent itself.
3. In the ObjectRenderer. This is similar to 2, but instead of asking
the LoggingEvent to resolve an unkown conversion character to a String,
the PatternLayout asks the ObjectRenderer associated with the logged
Object:
void format(Object msg, char conversionChar, StringBuffer sbuf);
The first argument might be the whole LoggingEvent instead of just the
logged Object.
Option 3 seems by far the best and most flexible to me, e.g.
- can accommodate per-Class custom conversion characters
- can accommodate different per-category rendering
- no need to subclass PatternLayout as in 1.
- no need to subclass Category and LoggingEvent as in 2.
I'm +1 on this scheme.
--
Anders Kristensen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
