Re: Logging configuration

[Claude Brisson]

So, I reviewed tools logging as proposed. Here's the default behavior:

 - structural classes log with 'org.apache.velocity.tools'

 - tools log with they key name, for instance 
'org.apache.velocity.tools.date' for the date tool.


And here's how it is configurable:

 - if runtime.log.instance is set to a valid logger in the engine, none 
of the following is used and the provided logger is used everywhere.


 - the 'org.apache.velocity' part is the one which is configurable in 
the engine via runtime.log.name


 - the tools have two new configuration values, useClassLogger and 
loggerName (which are mutually exclusive) to change the default behavior:


   x Setting useClassLogger = true (at any hierarchical level of the 
configuration) will let the tools get their logger via their class.
   x Seting loggerName =  (idem, anywhere in the configuration) 
explicitly specifies the logger 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 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 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 rather not use package names for sub-packages, since
"org.apache.velocity.rendering" is far more understandable than
"org.apache.velocity.runtime.utils.introspection"...

   Claude



On 11/11/2016 12:59, Greg Huber wrote:


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 2016 at 11:07, Claude Brisson  wrote:

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
   - velocity.loader and velocity.loader.[loadername]
   - velocity.macro
   - velocity.rendering (rendering errors other than directive ones,
introspector/uberspector)

Ah, and allso:
   - velocity.scripting for the JSR223 scripting module


plus:
   - velocity.tools
   - velocity.tools.[key]



On 11/11/2016 11:14, Claude Brisson wrote:

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 rather not use class names, because the logical hierarchy of modules
is not always reflected by the factual class hierarchy, and because
"org.apache.velocity.app.Velocity" is obviously redundant and verbose.
Not to mention "org.apache.velocity.runtime.r
esource.util.StringResourceRepositoryImpl"... Plus, we can have some
logger names reflect runtime objects as directives and loaders.

Now, to the modules themselves: we could have:

   - velocity for the app/runtime/singleton
   - velocity.event for the event cartridge
   - velocity.directive, and velocity.directive.[directivename]
   - velocity.parser
   - velocity.loader and velocity.loader.[loadername]
   - velocity.macro

Do you see something else?

Also, for the tools, we can have velocity.tools for the framework and
velocity.tools.[toolskey] instead of the tools class (which allows
custom
user tools to enter our hierarchy).

Thoughts?

Claude


On 10/11/2016 17:18, Mike Kienenberger wrote:

+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 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" level="WARN" for everything else.

The reasons we only have one logger are mainly historical. It would

certainly be more pertinent to have at least one logger per module,
loading,
introspection, etc...

But I you can filter the log file (in eclipse) so it makes no


difference.


Thanks for the velocity upgrade!  Thought it was not being maintained
any
more.

Well, we're kinda resurrecting...


 Claude

Re: Logging configuration

[Nathan Bubna]

+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 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 rather not use package names for sub-packages, since
> "org.apache.velocity.rendering" is far more understandable than
> "org.apache.velocity.runtime.utils.introspection"...
>
>   Claude
>
>
>
> On 11/11/2016 12:59, Greg Huber wrote:
>
>> 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 2016 at 11:07, Claude Brisson  wrote:
>>
>> 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
>>>   - velocity.loader and velocity.loader.[loadername]
>>>   - velocity.macro
>>>   - velocity.rendering (rendering errors other than directive ones,
>>> introspector/uberspector)
>>>
>>> Ah, and allso:
>>>   - velocity.scripting for the JSR223 scripting module
>>>
>>>
>>> plus:
>>>   - velocity.tools
>>>   - velocity.tools.[key]
>>>
>>>
>>>
>>> On 11/11/2016 11:14, Claude Brisson wrote:
>>>
>>> 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 rather not use class names, because the logical hierarchy of modules
 is not always reflected by the factual class hierarchy, and because
 "org.apache.velocity.app.Velocity" is obviously redundant and verbose.
 Not to mention "org.apache.velocity.runtime.r
 esource.util.StringResourceRepositoryImpl"... Plus, we can have some
 logger names reflect runtime objects as directives and loaders.

 Now, to the modules themselves: we could have:

   - velocity for the app/runtime/singleton
   - velocity.event for the event cartridge
   - velocity.directive, and velocity.directive.[directivename]
   - velocity.parser
   - velocity.loader and velocity.loader.[loadername]
   - velocity.macro

 Do you see something else?

 Also, for the tools, we can have velocity.tools for the framework and
 velocity.tools.[toolskey] instead of the tools class (which allows
 custom
 user tools to enter our hierarchy).

 Thoughts?

Claude


 On 10/11/2016 17:18, Mike Kienenberger wrote:

 +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 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" level="WARN" for everything else.
>>>
>>> The reasons we only have one logger are mainly historical. It would
>> certainly be more pertinent to have at least one logger per module,
>> loading,
>> introspection, etc...
>>
>> But I you can filter the log file (in eclipse) so it makes no
>>
>>> difference.
>>>
>>>
>>> Thanks for the velocity upgrade!  Thought it was not being maintained
>>> any
>>> more.
>>>
>>> Well, we're kinda resurrecting...
>>
>>
>> Claude
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
>> For additional commands, e-mail: dev-h...@velocity.apache.org
>>
>> -
>>
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>
>
> -
>>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
>>> For 

Re: Logging configuration

[Claude Brisson]

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 rather not use package names for sub-packages, since 
"org.apache.velocity.rendering" is far more understandable than 
"org.apache.velocity.runtime.utils.introspection"...


  Claude


On 11/11/2016 12:59, Greg Huber wrote:

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 2016 at 11:07, Claude Brisson  wrote:


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
  - velocity.loader and velocity.loader.[loadername]
  - velocity.macro
  - velocity.rendering (rendering errors other than directive ones,
introspector/uberspector)

Ah, and allso:
  - velocity.scripting for the JSR223 scripting module


plus:
  - velocity.tools
  - velocity.tools.[key]



On 11/11/2016 11:14, Claude Brisson wrote:


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 rather not use class names, because the logical hierarchy of modules
is not always reflected by the factual class hierarchy, and because
"org.apache.velocity.app.Velocity" is obviously redundant and verbose.
Not to mention "org.apache.velocity.runtime.r
esource.util.StringResourceRepositoryImpl"... Plus, we can have some
logger names reflect runtime objects as directives and loaders.

Now, to the modules themselves: we could have:

  - velocity for the app/runtime/singleton
  - velocity.event for the event cartridge
  - velocity.directive, and velocity.directive.[directivename]
  - velocity.parser
  - velocity.loader and velocity.loader.[loadername]
  - velocity.macro

Do you see something else?

Also, for the tools, we can have velocity.tools for the framework and
velocity.tools.[toolskey] instead of the tools class (which allows custom
user tools to enter our hierarchy).

Thoughts?

   Claude


On 10/11/2016 17:18, Mike Kienenberger wrote:


+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 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" level="WARN" for everything else.


The reasons we only have one logger are mainly historical. It would
certainly be more pertinent to have at least one logger per module,
loading,
introspection, etc...

But I you can filter the log file (in eclipse) so it makes no

difference.


Thanks for the velocity upgrade!  Thought it was not being maintained
any
more.


Well, we're kinda resurrecting...


Claude



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

-

To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Logging configuration

[Greg Huber]

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 2016 at 11:07, Claude Brisson  wrote:

> 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
>  - velocity.loader and velocity.loader.[loadername]
>  - velocity.macro
>  - velocity.rendering (rendering errors other than directive ones,
> introspector/uberspector)
>
> Ah, and allso:
>  - velocity.scripting for the JSR223 scripting module
>
>
> plus:
>  - velocity.tools
>  - velocity.tools.[key]
>
>
>
> On 11/11/2016 11:14, Claude Brisson wrote:
>
>> 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 rather not use class names, because the logical hierarchy of modules
>> is not always reflected by the factual class hierarchy, and because
>> "org.apache.velocity.app.Velocity" is obviously redundant and verbose.
>> Not to mention "org.apache.velocity.runtime.r
>> esource.util.StringResourceRepositoryImpl"... Plus, we can have some
>> logger names reflect runtime objects as directives and loaders.
>>
>> Now, to the modules themselves: we could have:
>>
>>  - velocity for the app/runtime/singleton
>>  - velocity.event for the event cartridge
>>  - velocity.directive, and velocity.directive.[directivename]
>>  - velocity.parser
>>  - velocity.loader and velocity.loader.[loadername]
>>  - velocity.macro
>>
>> Do you see something else?
>>
>> Also, for the tools, we can have velocity.tools for the framework and
>> velocity.tools.[toolskey] instead of the tools class (which allows custom
>> user tools to enter our hierarchy).
>>
>> Thoughts?
>>
>>   Claude
>>
>>
>> On 10/11/2016 17:18, Mike Kienenberger wrote:
>>
>>> +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 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" level="WARN" for everything else.
>

 The reasons we only have one logger are mainly historical. It would
 certainly be more pertinent to have at least one logger per module,
 loading,
 introspection, etc...

 But I you can filter the log file (in eclipse) so it makes no
> difference.
>
>
> Thanks for the velocity upgrade!  Thought it was not being maintained
> any
> more.
>

 Well, we're kinda resurrecting...


Claude



 -
 To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
 For additional commands, e-mail: dev-h...@velocity.apache.org

 -
>>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
>>> For additional commands, e-mail: dev-h...@velocity.apache.org
>>>
>>>
>>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: Logging configuration

[Claude Brisson]

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
 - velocity.loader and velocity.loader.[loadername]
 - velocity.macro
 - velocity.rendering (rendering errors other than directive ones, 
introspector/uberspector)


Ah, and allso:
 - velocity.scripting for the JSR223 scripting module


plus:
 - velocity.tools
 - velocity.tools.[key]



On 11/11/2016 11:14, Claude Brisson wrote:
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 rather not use class names, because the logical hierarchy of 
modules is not always reflected by the factual class hierarchy, and 
because "org.apache.velocity.app.Velocity" is obviously redundant and 
verbose. Not to mention 
"org.apache.velocity.runtime.resource.util.StringResourceRepositoryImpl"... 
Plus, we can have some logger names reflect runtime objects as 
directives and loaders.


Now, to the modules themselves: we could have:

 - velocity for the app/runtime/singleton
 - velocity.event for the event cartridge
 - velocity.directive, and velocity.directive.[directivename]
 - velocity.parser
 - velocity.loader and velocity.loader.[loadername]
 - velocity.macro

Do you see something else?

Also, for the tools, we can have velocity.tools for the framework and 
velocity.tools.[toolskey] instead of the tools class (which allows 
custom user tools to enter our hierarchy).


Thoughts?

  Claude


On 10/11/2016 17:18, Mike Kienenberger wrote:

+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 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" level="WARN" for everything else.


The reasons we only have one logger are mainly historical. It would
certainly be more pertinent to have at least one logger per module, 
loading,

introspection, etc...

But I you can filter the log file (in eclipse) so it makes no 
difference.



Thanks for the velocity upgrade!  Thought it was not being 
maintained any

more.


Well, we're kinda resurrecting...


   Claude



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Logging configuration

[Claude Brisson]

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 rather not use class names, because the logical hierarchy of modules 
is not always reflected by the factual class hierarchy, and because 
"org.apache.velocity.app.Velocity" is obviously redundant and verbose. 
Not to mention 
"org.apache.velocity.runtime.resource.util.StringResourceRepositoryImpl"... 
Plus, we can have some logger names reflect runtime objects as 
directives and loaders.


Now, to the modules themselves: we could have:

 - velocity for the app/runtime/singleton
 - velocity.event for the event cartridge
 - velocity.directive, and velocity.directive.[directivename]
 - velocity.parser
 - velocity.loader and velocity.loader.[loadername]
 - velocity.macro

Do you see something else?

Also, for the tools, we can have velocity.tools for the framework and 
velocity.tools.[toolskey] instead of the tools class (which allows 
custom user tools to enter our hierarchy).


Thoughts?

  Claude


On 10/11/2016 17:18, Mike Kienenberger wrote:

+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 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" level="WARN" for everything else.


The reasons we only have one logger are mainly historical. It would
certainly be more pertinent to have at least one logger per module, loading,
introspection, etc...


But I you can filter the log file (in eclipse) so it makes no difference.


Thanks for the velocity upgrade!  Thought it was not being maintained any
more.


Well, we're kinda resurrecting...


   Claude



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Logging configuration

[Mike Kienenberger]

+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 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" level="WARN" for everything else.
>
>
> The reasons we only have one logger are mainly historical. It would
> certainly be more pertinent to have at least one logger per module, loading,
> introspection, etc...
>
>> But I you can filter the log file (in eclipse) so it makes no difference.
>>
>>
>> Thanks for the velocity upgrade!  Thought it was not being maintained any
>> more.
>
>
> Well, we're kinda resurrecting...
>
>
>   Claude
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Logging configuration

[Greg Huber]

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" level="WARN" for everything else.

But I you can filter the log file (in eclipse) so it makes no difference.


Thanks for the velocity upgrade!  Thought it was not being maintained any
more.

Cheers Greg

On 10 November 2016 at 14:13, Claude Brisson  wrote:

> 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 the application, each module can use its own
> logger. The parameter is generally used as a log line prefix, and can also
> be used to do a fine tuning of which modules can log at which log level,
> something we haven't taken advantage so far in Velocity (apart for the
> Tools themselves).
>
> I chose to use the first variant for sobriety (to avoid each log line
> contain the whole package name), but it s not necessarily a definitive
> choice. At least, it should be better documented.
>
> Does your logging work properly with this configuration?
>
>   Claude
>
>
> On 10/11/2016 11:12, Greg Huber wrote:
>
>> 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 = LoggerFactory.getLogger("Velocity");
>>
>>
>> Then I do not use slf4j so not sure how it should be configured ie per
>> package.
>>
>> Cheers Greg
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

Re: Logging configuration

[Claude Brisson]

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 the application, each module can use its own 
logger. The parameter is generally used as a log line prefix, and can 
also be used to do a fine tuning of which modules can log at which log 
level, something we haven't taken advantage so far in Velocity (apart 
for the Tools themselves).


I chose to use the first variant for sobriety (to avoid each log line 
contain the whole package name), but it s not necessarily a definitive 
choice. At least, it should be better documented.


Does your logging work properly with this configuration?

  Claude


On 10/11/2016 11:12, Greg Huber wrote:

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 = LoggerFactory.getLogger("Velocity");


Then I do not use slf4j so not sure how it should be configured ie per
package.

Cheers Greg




-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org