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 > >
