Thank you for the feedback. I can see that I could invent a new kind of %m converter that parses the message and does the coloring. I could have an ANSI kind of %m, an HTML %m, and so on.
Gary On Jun 24, 2016 10:00 AM, "Ralph Goers" <[email protected]> wrote: > > I am not sure I get this idea at all. First, I would expect that “styles” > would be plugins much as converters are for the PatternLayout. But it isn’t > clear to me at all why I would want or require a StyledMessage to do that. > If you want to support “styles” then implement the support in the > appropriate layouts. The message should just contain the information the > styles need to render them. > > Also, is StyledMessage an Interface? If it is a class is it a > ParameterizedMessage, SimpleMessage, etc, or are you planning on having a > “Styled” version of each Message type. I am not in favor of that at all. > > I am also not sure how this handles the issue you mentioned at the start > of this thread - that the color codes written to files don’t cause the > colors to show up and only render properly on the console. > > Ralph > > On Jun 24, 2016, at 8:43 AM, Gary Gregory <[email protected]> wrote: > > Another question is what should the syntax be for a StyledMessage? The > same as for a pattern layout ( > https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout)? > Something else? Could it be simpler and still allow for parameters and > escaping? > > SyledMessageFactory factory = SyledMessageFactory.load( ...styles... ); > item = "pants"; > // Using pattern layout kind of format with parameter markers. > logger.error("Your {} are on {fire!}{criticalMassStyle}, > {notifying}{peacfulStyle}{}", item); > logger.error("Your %s are on {fire!}{criticalMassStyle}, > {notifying}{peacfulStyle}%s", item); > > Gary > > On Tue, Jun 21, 2016 at 6:39 PM, Remko Popma <[email protected]> > wrote: > >> After thinking about it some more, I agree with you guys that the string >> syntax seems like a better idea. >> >> >> On Wednesday, 22 June 2016, Gary Gregory <[email protected]> wrote: >> >>> On Mon, Jun 20, 2016 at 4:14 PM, Remko Popma <[email protected]> >>> wrote: >>> >>>> What if we keep the same or similar syntax but with Log4j2 imports, and >>>> we use it to build a custom Message? >>>> >>>> So, this java code logger.info(ansi().fg(RED).a("Hello").fg(CYAN).a(" >>>> World").reset()); >>>> would result in a JansiMessage containing a "Hello" string associated >>>> with a RED object, and a " World" string associated with the CYAN object. >>>> At this stage, nothing is rendered yet. >>>> >>> >>> I would prefer to avoid a vendor specific message class and name. I >>> think the Maven folks are experiencing growing pains now that they have >>> enabled color within Maven messages. I think a StyledMessage would be the >>> way to go. >>> >>> When a StyledMessage goes to a Console appender, JAnsi is used, when it >>> does to an HTML appender, HTML is used. Whether you build a StyledMessage >>> with a fluent API, a string syntax or both is another matter, but the >>> string syntax seems simplest. >>> >>> Gary >>> >>> >>>> The Console Appender's PatternLayout, when the Jansi option is enabled, >>>> could call JansiMessage.generateJansiFormattedMessage() which contains the >>>> escape codes for the console. >>>> >>>> The File Appender's PatternLayout does not have the Jansi option >>>> enabled, so the normal Message.getFormattedMessage() is called, resulting >>>> in the plain string "Hello World". >>>> >>>> One key consideration is that all the objects used to build the message >>>> should be in the Log4j API namespace to avoid any dependency on Jansi at >>>> the API level. (But things like RED etc can be inner classes of >>>> JansiMessage. Static imports can make this painless to use.) >>>> >>>> >>>> On Tue, Jun 21, 2016 at 3:59 AM, Paul Benedict <[email protected]> >>>> wrote: >>>> >>>>> It's pretty cool. Yes, a generalized syntax is very nice. Do your best >>>>> to make the syntax general -- and if for, for whatever reason, an appender >>>>> needs something more explicit/specific, those options can just be provided >>>>> by the appender's custom parsing. >>>>> >>>>> Cheers, >>>>> Paul >>>>> >>>>> On Mon, Jun 20, 2016 at 1:44 PM, Gary Gregory <[email protected]> >>>>> wrote: >>>>> >>>>>> 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 >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> 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 > > >
