[slf4j-user] Questions about formattedMessage

[Chris Pratt]

Well, I can assure you that it should never throw an exception, but yes it
will not show what was intended.  Which is similar to the problem of
changing types in MessageFormat.  If you change an ID from long to String
but don't change from {0,number,integer}, you will get an exception I
believe (which won't happen in Anodyzed's TextFormat, it will be silently
ignored like the missing method name).  So MessageFormat doesn't give you
"type-safety" per se, and even it's parameter number check is done at
run-time, not compile-time.
  (*Chris*)

On Thu, Aug 2, 2012 at 1:01 PM, niels <opensource21 at gmail.com> wrote:

> 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
> _______________________________________________
> slf4j-user mailing list
> slf4j-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-user/attachments/20120802/a6161615/attachment-0001.html>