Re: Logging configuration

to be used. The logging configuration is gathered in the generic.SafeConfig class (which has become a base class for all standard tools). Loggers are not any more static, but at least it allows this factorization. Claude On 11/11/2016 15:30, Nathan Bubna wrote: +1 for logical names

Re: Logging configuration

+1 for logical names and a configurable base. On Fri, Nov 11, 2016 at 6:24 AM, Claude Brisson wrote: > In fact, the logger name (well, *base* logger name) is configurable. So we > can both be happy: we can have the default base logger name be > "org.apache.velocity", as like

Re: Logging configuration

In fact, the logger name (well, *base* logger name) is configurable. So we can both be happy: we can have the default base logger name be "org.apache.velocity", as like you say it is more intuitive, and people like me willing to shorten it can still tune their config file. But as I said, I'd

Re: Logging configuration

Doing only casual debugging, as long as its intuitive to set the debugging name="foobar" name without having to dip into the code sounds great. The package name is however the easiest to remember as its from the class you are trying to debug (using attached source jar). Thanks On 11 November

Re: Logging configuration

And also velocity.rendering for every rendering error (including introspector/uberspector). So here's the new list: - velocity for the app/runtime/singleton - velocity.event for the event cartridge - velocity.directive, and velocity.directive.[directivename] - velocity.parser -

Re: Logging configuration

Why not, but it should be done right now to take advantage of the major version change. I checked quickly, and it seems like all logging backends build the loggers hierarchy using namespaces separated with dots, which can be class names by convention but it is not at all necessary. I'd

Re: Logging configuration

+1 to using several appropriate functional names if we are picking loggers by String rather than by Class. On Thu, Nov 10, 2016 at 11:11 AM, Claude Brisson wrote: > On 10/11/2016 15:56, Greg Huber wrote: > >> Yes it does when I use name="Velocity" >> >> But as you are using

Re: Logging configuration

Yes it does when I use name="Velocity" But as you are using the runtime instance logger its either on or off for the whole package. Using a per class I think enables more filtering as you can name="org.apache.velocity.app" level="DEBUG" purely for this package and name="org.apache.velocity"

Re: Logging configuration

Any module anywhere can get a logger using one of the two static methods: Logger org.slf4j.LoggerFactory.getLogger(String loggerName) Logger org.slf4j.LoggerFactory.getLogger(Class targetClass) Calling one or the other is a matter of taste. It does not *have* to be the same logger anywhere in

Logging configuration

The name needs to be exactly Velocity which is not what I had expected, usually its the package name format ie org.apache.velocity. the docs suggest its org.apache.velocity.app.Velocity This seems to be set in RuntimeInstance: private Logger log =

[jira] Updated: (VELOCITY-559) Log4j logging configuration guide is outdated/wrong

[ https://issues.apache.org/jira/browse/VELOCITY-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna updated VELOCITY-559: -- Fix Version/s: (was: 1.6) Log4j logging configuration guide is outdated/wrong

[jira] Resolved: (VELOCITY-559) Log4j logging configuration guide is outdated/wrong

in 1.6, this was/is a 1.5.1 CANDIDATE Log4j logging configuration guide is outdated/wrong --- Key: VELOCITY-559 URL: https://issues.apache.org/jira/browse/VELOCITY-559 Project: Velocity Issue

[jira] Commented: (VELOCITY-559) Log4j logging configuration guide is outdated/wrong

666295. Leaving unresolved in case there's a 1.5.1 release, as this should be included. Log4j logging configuration guide is outdated/wrong --- Key: VELOCITY-559 URL: https://issues.apache.org/jira/browse