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 <cla...@renegat.net> 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 <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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
