[slf4j-user] Questions about formattedMessage

[niels]

Well for the MessageFormatter there can only the number of arguments
greater or smaller than the number of variables meaning {}.
If the number of arguments is smaller, it's not a problem. The message
is perhaps not nice but you don't loose any information.
If the number of arguments is grater, it's a problem, because some of
the arguments will be lost.
I think this can easily fix.
With anodyzed a further problem can occur. You rename person.getName
to person.getLastname(), then the log of [{0.name}] will become
useless or more worst will throw an exception.

Niels

2012/8/2 Chris Pratt <thechrispratt at gmail.com>:
> I'm not sure how you could preserve compiler type-safety with a text
> formatting language.  Can you elaborate?
>   (*Chris*)
>
>
> On Thu, Aug 2, 2012 at 12:50 PM, niels <opensource21 at gmail.com> wrote:
>>
>> Thanks for the explanation. I hope someone has measured that it's really
>> faster.
>> The idea of anodyzed is indeed interesting, but my critic on
>> MessageFormatter was that it is not robust enough. So it's possible
>> you loose information. With anodyzed I loose the compiler safeness. So
>> it's definitely not an option.
>>
>> Can anyone give an answer about my idea of improvement "Any change
>> that the MessageFormatter will be changed, so that if
>> L>argArray.length the additional array-information will simply added
>> at the end?"
>> Niels
>>
>> 2012/8/2 Chris Pratt <thechrispratt at gmail.com>:
>> > The java.text.MessageFormat is designed to be bi-directional (it parses
>> > as
>> > well as formats), which adds complexity and time.  So there is
>> > definitely
>> > room for improvement in the performance.  Both Ceki's {} processing and
>> > Onyx's processing (whose format is extended directly from the
>> > java.text.MessageFormat) are uni-directional formatters that are
>> > developed
>> > for speed.
>> >   (*Chris*)
>> >
>> >
>> > On Thu, Aug 2, 2012 at 9:31 AM, niels <opensource21 at gmail.com> wrote:
>> >>
>> >> My question is, why the internal implementation doesn't use the
>> >> standard-formatter class. Can't see any argument in
>> >> logging_performance.
>> >> Niels
>> >>
>> >> 2012/8/2 Roman Muntyanu <rmuntyan at softserveinc.com>:
>> >> >>> Furthermore I wonder what are the reasons that you don't use the
>> >> >>> Formatter-class of the JDK which has more possibilities.
>> >> > Because of http://www.slf4j.org/faq.html#logging_performance
>> >> >
>> >> > -----Original Message-----
>> >> > From: slf4j-user-bounces at qos.ch [mailto:slf4j-user-bounces at qos.ch] On
>> >> > Behalf Of niels
>> >> > Sent: Thursday, August 02, 2012 12:55 PM
>> >> > To: slf4j-user at qos.ch
>> >> > Subject: [slf4j-user] Questions about formattedMessage
>> >> >
>> >> > Hi
>> >> > I restart thinking about to create a fluid-log-facade for java. The
>> >> > idea
>> >> > is to write log.onError().aMessage("test") or
>> >> > log.onDebug().aParmameter("param").withValue(1). One idea is to have
>> >> > something like formattedMessage("A {} test", "small"). I see that
>> >> > slf4j has
>> >> > something similar.
>> >> > Unfortunately I found the the implementation not reliable enough. The
>> >> > problem is the following situation (I had in real-life last year,
>> >> > where a
>> >> > formatter was used): If you have formattedMessage("At {} the
>> >> > following error
>> >> > happens", "myMethod", e.getMessage()). So the devoloper has simply
>> >> > forget to
>> >> > add the {} at the messagepattern. Then the really important
>> >> > information is
>> >> > lost. Any change that the MessageFormatter will be changed, so that
>> >> > if
>> >> > L>argArray.length the additional array-information will simply added
>> >> > at the
>> >> > end?
>> >> >
>> >> > Furthermore I wonder what are the reasons that you don't use the
>> >> > Formatter-class of the JDK which has more possibilities.
>> >> >
>> >> > Best regards
>> >> > Niels
>> >> > _______________________________________________
>> >> > slf4j-user mailing list
>> >> > slf4j-user at qos.ch
>> >> > http://mailman.qos.ch/mailman/listinfo/slf4j-user
>> >> > _______________________________________________
>> >> > slf4j-user mailing list
>> >> > slf4j-user at qos.ch
>> >> > http://mailman.qos.ch/mailman/listinfo/slf4j-user
>> >> _______________________________________________
>> >> slf4j-user mailing list
>> >> slf4j-user at qos.ch
>> >> http://mailman.qos.ch/mailman/listinfo/slf4j-user
>> >
>> >
>> >
>> > _______________________________________________
>> > slf4j-user mailing list
>> > slf4j-user at qos.ch
>> > http://mailman.qos.ch/mailman/listinfo/slf4j-user
>> _______________________________________________
>> slf4j-user mailing list
>> slf4j-user at qos.ch
>> http://mailman.qos.ch/mailman/listinfo/slf4j-user
>
>
>
> _______________________________________________
> slf4j-user mailing list
> slf4j-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user