I like the idea of markers, seems like a clean way to support extensibility.
On Tue, Oct 8, 2013 at 2:47 PM, Ralph Goers <[email protected]>wrote: > Is there some reason you can't do: > > public static final Marker VERBOSE_MARKER = > MarkerManager.getMarker("VERBOSE"); > > > and then logger.info(VERBOSE_MARKER, "Reading Accounts"); > > then in your configuration you would do > > <MarkerFilter marker="VERBOSE" onMatch="ACCEPT" onMismatch="DENY"/> > > and finally, in your Appender you could use a PatternLayout that includes > > pattern="%p %marker %msg" > > You could also wrap the marker in a %replace so that you don't end up with > two spaces when there is not Marker. > > The point is that the purpose of Markers is to fill the need for these > kinds of things without needing to create an endless number of logging > levels. Remember that every new Level that gets added causes 14 new methods > to be added to the Logger interface. > > Another consideration is that if a new level was added between info and > debug when mapping the Log4j 2 API to SLF4J we would have to make an > arbitrary choice as to whether the events should be mapped to INFO or DEBUG > since SLF4J (as well as JCL) don't have a corresponding level. OTOH, JUL > has a CONFIG level between FINE and INFO, which seems to correlate to the > examples you show. > > > On Oct 7, 2013, at 8:50 PM, Gary Gregory <[email protected]> wrote: > > On Mon, Oct 7, 2013 at 11:16 PM, Scott Deboy <[email protected]>wrote: > >> If your examples included loggers I think it would show these added >> verbose entries would be another logger at INFO but not a separate severity. >> >> I think of levels in terms of relative numeric severity. DEBUG < INFO >> <WARN <ERROR etc. Chainsaw supports this kind of logic in filtering >> colorizing and searching for events. >> >> Where would verbose go? I would put it below DEBUG myself. >> > > I should not have proposed a name for this level since 'verbose' means > different things to different people. As I stated in my original message, > this new level would be between INFO and DEBUG. > > Gary > > >> Btw this advice to use another logger in most cases doesn't mean there >> aren't cases where additional levels aren't useful. >> >> Just something to think about. >> >> Scott >> On Oct 7, 2013 7:30 PM, "Gary Gregory" <[email protected]> wrote: >> >>> Hi All: >>> >>> I've just come across the need for distinguishing log entries somewhat >>> between what INFO and DEBUG provide. >>> >>> I think of the DEBUG level as a watermark where data is provided for >>> developers and support to do deep debugging. INFO is for users. But I see >>> the need now for providing an easy way to give user more information (hence >>> VERBOSE or another word) which is not at the DEBUG level of detail. >>> >>> Ideally, I'd like this in INFO mode: >>> >>> INFO Reading configuration >>> INFO Running server >>> >>> Then in a new VERBOSE mode: >>> >>> INFO Reading configuration >>> VERBOSE Reading accounts >>> VERBOSE Reading this config data >>> VERBOSE Reading that config data >>> VERBOSE Reading other config data >>> INFO Running server >>> >>> The in DEBUG mode, you'd get all the things that are real debug >>> information like >>> >>> DEBUG Configuration location was not provided on the command line. >>> DEBUG Searching classpath for configuration: cp entries >>> DEBUG Searching user home for configuration: c:\users\... >>> DEBUG Found configuration at location xzy, last modified date: ... >>> INFO Reading configuration >>> >>> Thoughts? >>> >>> -- >>> 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 > > >
