You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-user@logging.apache.org by "Madan, Hatinder" <ha...@gs.com> on 2004/12/23 10:52:26 UTC

Question about maximum field width modifier

Hi,
 I would like to truncate a field that exceeds its maximum length, from the
end.
But this is what the documentation of log4cxx says:
If the data item is longer than the maximum field, then the extra characters
are removed from the beginning of the data item and not from the end
Is it possible to configure the layout in some way to achieve the truncation
from the end?

Your suggestions would be appreciated.

Thanks,
Hatinder

Re: Question about maximum field width modifier

Posted by Curt Arnold <ca...@apache.org>.
On Dec 23, 2004, at 3:52 AM, Madan, Hatinder wrote:

> Hi,
>  I would like to truncate a field that exceeds its maximum length, 
> from the end.
> But this is what the documentation of log4cxx says:
> If the data item is longer than the maximum field, then the extra 
> characters are removed from the beginning of the data item and not 
> from the end
>
> Is it possible to configure the layout in some way to achieve the 
> truncation from the end?
>
> Your suggestions would be appreciated.
>


I did a quick check of  "A complete guide to log4j" and scanned its 
source code and the corresponding classes in log4cxx.
I didn't see anything to suggest that it had a mechanism to choose 
between beginning and ending truncation.

On new features that aren't C++ specific, we try to follow log4j and 
not introduce features here first.  If you'd like to pursue this, I 
would suggest starting a discussion on the log4j list (likely just copy 
this to the log4j-dev mailing list) or trying to mock up an 
implementation for log4j and submit it as a patch and we can then 
transliterate it into log4cxx.

The key classes appear to be org.apache.log4j.pattern.FormattingInfo 
and o.a.l.p.PatternParser.  FormattingInfo would need to have a 
leftTruncation member added with a default value of true to maintain 
this piece of info.   PatternParser would need to be modified to 
recognize the pattern to suggest right truncation.  And the code that 
acts on FormattingInfo would obviously need to be changed, but I 
haven't tried to find it.

The most obvious choice to me for simple right truncation is "%30.c".  
The undesirable aspect is this could also be an incomplete left 
truncated range (like they dropped the 99 from %30.99c").  Then you'd 
also need to consider how to do a right truncated range (though I'd 
expect it to be rare), it is a little busy, but %30.99.c" would be 
okay.