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 <cla...@renegat.net> 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
