Thomas Tuft Muller wrote:
>
> Anders Kristensen wrote:
> | Thomas Tuft Muller wrote:
> | > 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().
>
> Not it version 1.0.4 ;) I've downloaded the latest now.
>
> | > 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?
>
> [snip]
> | 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);
>
> Do you sugges the the ObjectRenderer implements this method? If this is the
> case, some checking and casting must be done somewhere.
The method would be added to the ObjectRenderer interface. No checking
or casting is needed anywhere.
Maybe I wasn't being clear about it, but the proposal is to add support
for what you ask for in log4j itself. If you wanted to use this scheme
yourself on top of 1.1.1 or earlier versions of log4j, you would indeed
have to cast the ObjectRenderer in your PatternLayout.
>
> | 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
>
> Yes.
>
> | - can accommodate different per-category rendering
>
> How? Renderers are still global or what? Do you suggest that the renderer
> gets information about the category calling it in order to differentiate?
Renderers are global but Layouts are not. Rendering would use
PatternLayout with conversion strings containing custom conversion
characters. These are resolved by the ObjectRenderer, but different
Categories may have different conversion strings.
One objection to what I'm proposing would be that it elevates one
particular Layout to a special status. The log4j "core" includes the
notion of ObjectRenderers and Layouts, but is completely agnostic of how
particular Layouts do their job. This proposal would give special status
to PatternLayout in that the ObjectRenderer interface would have a
method specially designed to work with it.
I think in reality, however, there is only really one Layout. The other
ones which are part of log4j can be seen as shorthands for
PatternLayout, and the layouts users write themselves are mostly
concerned, I believe, with logging custom objects, and so would likely
benefit from this extension.
>
> | - no need to subclass PatternLayout as in 1.
>
> How can I call the "custom" method on the renderer if I don't subclass
> PatternLayout?
It would be done by PatternLayout itself in a future modified version.
If you want to implement this scheme now, you do need to write a simple
extension to PatternLayout which handles costum conversion characters by
obtaining the objectrenderer for the logged Object, casts it, and
invokes the format method. It's a lot less attractive if not part of
log4j itself.
--
Anders Kristensen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
