I think like the idea of having a special syntax for colors, for rendering of styles in general actually, because we could have this implemented for the Jansi+Console appender, for the HTML appender, and you could also imagine an RTF appender.
Gary On Thu, Jun 16, 2016 at 12:59 PM, Gary Gregory <[email protected]> wrote: > On Thu, Jun 16, 2016 at 12:48 PM, Paul Benedict <[email protected]> > wrote: > >> I imagine parsing the placeholder is going to be expensive (relatively >> speaking). It is an extra cost. >> > > We already support different ways to paramaterize messages [1]: {}, %s > (and family), java.text.MessageFormat, and so on. Each has its different > overhead. > > This could be a variation of the ParameterizedMessage class for example. > Or maybe an extension of to one or more other message types. > > Gary > > [1] https://logging.apache.org/log4j/2.x/manual/messages.html > > >> I advise devising a new interface that appenders can implement to receive >> the parsed tokens. If the interface is missing, no parsing in-between is >> necessary. Otherwise, send the tokens to the appender as a callback for it >> to make the necessary modifications -- such as setting the color. >> >> Cheers, >> Paul >> >> On Thu, Jun 16, 2016 at 1:53 PM, Gary Gregory <[email protected]> >> wrote: >> >>> >>> On Jun 16, 2016 11:25 AM, "Paul Benedict" <[email protected]> wrote: >>> > >>> > Are you asking me for blue sky thinking, perhaps something like this: >>> > log.info("Hello, {color:green}, how are you?", "Gary"); >>> > >>> > For this example, I took the {} placeholder and added some context. >>> >>> Ok yes, that's what I was talking about. Also: >>> >>> log.info("Hello {color:green Gary}, how are you?"); >>> >>> Gary >>> > >>> > Cheers, >>> > Paul >>> > >>> > On Thu, Jun 16, 2016 at 1:22 PM, Gary Gregory <[email protected]> >>> wrote: >>> >> >>> >> On Thu, Jun 16, 2016 at 11:04 AM, Paul Benedict <[email protected]> >>> wrote: >>> >>> >>> >>> I think color falls into the category of formatting. By that, I mean >>> to state that colors shouldn't be hardcoded into messages :-) That should >>> belong to the actual formatter... template string or appender configuration. >>> >> >>> >> >>> >> What would that look like? I do not see how do to that without >>> creating a lot of custom code. >>> >> >>> >> Gary >>> >> >>> >>> >>> >>> >>> >>> Cheers, >>> >>> Paul >>> >>> >>> >>> On Thu, Jun 16, 2016 at 12:58 PM, Gary Gregory < >>> [email protected]> wrote: >>> >>>> >>> >>>> On Thu, Jun 16, 2016 at 10:39 AM, Gary Gregory < >>> [email protected]> wrote: >>> >>>>> >>> >>>>> On Wed, Jun 15, 2016 at 10:50 PM, Gary Gregory < >>> [email protected]> wrote: >>> >>>>>> >>> >>>>>> Hi All, >>> >>>>>> >>> >>>>>> See color messages in Maven 3.4.0-SNAPSHOT made me think of the >>> following. >>> >>>>>> >>> >>>>>> Right now, with Jansi on the CP, I can say: >>> >>>>>> >>> >>>>>> import static org.fusesource.jansi.Ansi.*; >>> >>>>>> import static org.fusesource.jansi.Ansi.Color.*; >>> >>>>>> ... >>> >>>>>> logger.info(ansi().fg(RED).a("Hello").fg(CYAN).a(" >>> World").reset()); >>> >>>>>> >>> >>>>>> and the right thing happens on the console. >>> >>>>>> >>> >>>>>> If I also have a file appender, I get the escape codes in the >>> file, which I do not think most people would want. >>> >>>>>> >>> >>>>>> The question is, how can we make it simple for users to have >>> their cake and eat it too? >>> >>>>>> >>> >>>>>> With a special Message implementation? >>> >>>>>> >>> >>>>>> Thoughts? >>> >>>>> >>> >>>>> >>> >>>>> One way would be to have the non-a() methods (plus reset()) become >>> no-ops when not using a console appender. But how? We could have a subclass >>> of JAnsi's Ansi class that gets used. Anyway, I'm just rambling. >>> >>>> >>> >>>> >>> >>>> Still rambling, mostly so I have a place to look back for these >>> notes: >>> >>>> >>> >>>> - nope, the reset() method would need to be noop'd. >>> >>>> - Example of a color message: >>> org.apache.logging.log4j.core.appender.ConsoleAppenderJAnsiMessageMain >>> >>>> - JAnsi also supports a special syntax, for example: >>> >>>> >>> >>>> "@|red Hello|@ @|cyan World|@" >>> >>>> >>> >>>> but if use that like: >>> >>>> >>> >>>> logger.info("@|red Hello|@ @|cyan World|@"); >>> >>>> >>> >>>> JAnsi rendering does not kick in unsurprisingly. >>> >>>> >>> >>>> Maybe the Console appender could make sure the JAnsi renderer is >>> used (optional), so that >>> >>>> >>> >>>> logger.info(ansi().render("@|red Hello|@ @|green World|@"); >>> >>>> >>> >>>> can become: >>> >>>> >>> >>>> logger.info("@|red Hello|@ @|green World|@"); >>> >>>> >>> >>>> and then we can add a renderJansi option to the console appender >>> but... the decorations still end up in a file appender so we are still in >>> the same pickle. >>> >>>> >>> >>>> Thinking about a MessageRenderer (String render(String)) interface >>> with two impl: one that calls ansi().render(String) for console appenders >>> (optionally, if renderJansi=true) and another that strips the decorations >>> (but this feels heavy). >>> >>>> >>> >>>> More rambling: >>> >>>> >>> >>>> Instead of: >>> >>>> >>> >>>> logger.info(ansi().fg(RED).a("Hello").fg(CYAN).a(" >>> World").reset()); >>> >>>> >>> >>>> say: >>> >>>> >>> >>>> logger.info((Ansi ansi) -> ansi.fg(RED).a("Hello").fg(CYAN).a(" >>> World").reset()); >>> >>>> >>> >>>> Then we can pass in a custom Ansi subclass that only outputs the >>> string bits, no escape codes. >>> >>>> >>> >>>> Gary >>> >>>> >>> >>>>> >>> >>>>> Gary >>> >>>>> >>> >>>>>> >>> >>>>>> Thank you, >>> >>>>>> Gary >>> >>>>>> -- >>> >>>>>> E-Mail: [email protected] | [email protected] >>> >>>>>> Java Persistence with Hibernate, Second Edition >>> >>>>>> JUnit in Action, Second Edition >>> >>>>>> Spring Batch in Action >>> >>>>>> Blog: http://garygregory.wordpress.com >>> >>>>>> Home: http://garygregory.com/ >>> >>>>>> Tweet! http://twitter.com/GaryGregory >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> E-Mail: [email protected] | [email protected] >>> >>>>> Java Persistence with Hibernate, Second Edition >>> >>>>> JUnit in Action, Second Edition >>> >>>>> Spring Batch in Action >>> >>>>> Blog: http://garygregory.wordpress.com >>> >>>>> Home: http://garygregory.com/ >>> >>>>> Tweet! http://twitter.com/GaryGregory >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> E-Mail: [email protected] | [email protected] >>> >>>> Java Persistence with Hibernate, Second Edition >>> >>>> JUnit in Action, Second Edition >>> >>>> Spring Batch in Action >>> >>>> Blog: http://garygregory.wordpress.com >>> >>>> Home: http://garygregory.com/ >>> >>>> Tweet! http://twitter.com/GaryGregory >>> >>> >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> E-Mail: [email protected] | [email protected] >>> >> Java Persistence with Hibernate, Second Edition >>> >> JUnit in Action, Second Edition >>> >> Spring Batch in Action >>> >> Blog: http://garygregory.wordpress.com >>> >> Home: http://garygregory.com/ >>> >> Tweet! http://twitter.com/GaryGregory >>> > >>> > >>> >> >> > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
