+1 for logical names and a configurable base. On Fri, Nov 11, 2016 at 6:24 AM, Claude Brisson <cla...@renegat.net> 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 <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 > >
