[slf4j-user] Replaceable MessageFormatter

[Chris Pratt]

The intent would be to extend on what you started.  You recognized that
constructing a string to be thrown away when it was determined the logging
level was insufficient was inefficient, which is totally true, but it fails
to take into consideration that just accessing and formatting the data for
display can be quite costly as well.  I would propose to extend the already
existing replacement parameters, giving them the ability to be positionally
referenced, dot notated, and format specified to prevent retrieving and
formatting data before it's known that the data is necessary.  I would
propose to merge (and extend) my Onyx text formatter to be a perfect
superset of the existing MessageFormatter.  This should remove the concern
that different libraries would be requiring different formatters since old
libraries would continue to use the existing replacement syntax, where as
updated libraries/applications could take advantage of the advanced
formatters to allow for additional production speed improvements without
cluttering up their code with numerous if(log.isDebugEnabled()) { blocks.

I have a little time right now and would enjoy the challenge, but only if
there's a chance that it would be accepted as part of a future SLF4j
release.  Thanks.
  (*Chris*)


On Thu, Dec 26, 2013 at 10:22 AM, Ceki Gülcü <ceki at qos.ch> wrote:

> It depends. What do you have in mind?
>
>
> On 12/26/2013 5:09 PM, Chris Pratt wrote:
>
>> Hmmm, interesting point.  Would you be open to the possible extension of
>> the existing formatter?
>>    (*Chris*)
>>
>>
>> On Thu, Dec 26, 2013 at 2:19 AM, Ceki Gülcü <ceki at qos.ch
>> <mailto:ceki at qos.ch>> wrote:
>>
>>
>>     Hi Chris,
>>
>>     It is not possible to configure a different  MessageFormatter than
>>     the default. The current API does not and will not support changing
>>     the MessageFormatter because allowing for such changes would open
>>     the door for errors. For example, if your application A depends on
>>     library L, and F1 and F2 are two formatting conventions, then if A
>>     uses format F1 and L uses F2, then any choice of formatting
>>     convention would cause errors either in A or in L.
>>
>>     Merry Christmas and happy holidays,
>>
>>
>>     On 12/26/2013 6:52 AM, Chris Pratt wrote:
>>
>>         Ceki,
>>             I thought I had read that with the latest SLF4j it was
>>         possible to
>>         configure a different MessageFormatter than the default.  But,
>>         looking
>>         at the code, It doesn't appear possible.  What would I need to
>>         do to get
>>         a code modification to SLF4j reviewed and possibly approved?  Is
>>         it as
>>         simple as providing a GitHub Pull Request to you or is there
>>         something I
>>         would need to sign before that would be allowed?  Thanks.
>>             (*Chris*)
>>
>>
>>         _________________________________________________
>>         slf4j-user mailing list
>>         slf4j-user at qos.ch <mailto:slf4j-user at qos.ch>
>>         http://mailman.qos.ch/mailman/__listinfo/slf4j-user
>>         <http://mailman.qos.ch/mailman/listinfo/slf4j-user>
>>
>>     _________________________________________________
>>     slf4j-user mailing list
>>     slf4j-user at qos.ch <mailto:slf4j-user at qos.ch>
>>     http://mailman.qos.ch/mailman/__listinfo/slf4j-user
>>
>>     <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/20131226/63c10fe1/attachment.html>