Re: query - default logging behavior
I haven't much time for this today, but here's my initial thoughts: - As it is, my last bought of logging upgrades made the default lookup order: LogKit, Log4j, JDK logging, and StandardOutLogChute (which sends error to Std.out and error to Std.err). This still seems appropriate for me and will already not create a velocity.log file unless Avalon LogKit or Log4j are available and a runtime.log property is set. - So killing the velocity.log file is as easy as not using velocity-dep.jar and/or setting runtime.log = - I know this only sort of a B.C. concern, but it isn't really a trivial change either. - I'm of the view that Std.err is for errors (and maybe warnings), and is Std.out really redirected that often? And when it is, is that really our concern? Seems to me anyone redirecting Std.out should be prepared for surprises or least they shouldn't be critical. So, all that is to say that i currently am: -0 on removing Log4j and LogKit from the default lookup order in 1.5 -1 on punting trace/info/debug messages to Std.err +0 on punting warning messsages to Std.err -1 on putting StandardOutLogChute or kin before JdkLogChute in the lookup order +1 for tweaking this later on when we drop LogSystem support et al On 10/10/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, As you can see with the log messages, we're making some headway on a variety of Velocity issues this week. One quick item for discussion. The default logging behavior is to create a file velocity.log in the current directory. This is really quite annoying in a webapp or integrated app. One of my colleagues built a quick email routine using Velocity in a webapp. Now, I see a velocity.log file created on my Linux server in whatever directory I happened to be in when I started Tomcat! Here's the suggestion. Switch the default logging to StdErr. I'd suggested something similar in VELOCITY-403, but there was no resolution. STDERR is preferred to STDOUT so that it doesn't mess up existing log files if out is redirected. Consequence... happier web developers. Possible problem - command line apps which depend on Velocity.log being created don't see it. Any comments? WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: query - default logging behavior
So - if a user deploys this without the Avalong LogKit there's no velocity.log automatically created? That seems ok to me. WILL On 10/10/06, Nathan Bubna [EMAIL PROTECTED] wrote: I haven't much time for this today, but here's my initial thoughts: - As it is, my last bought of logging upgrades made the default lookup order: LogKit, Log4j, JDK logging, and StandardOutLogChute (which sends error to Std.out and error to Std.err). This still seems appropriate for me and will already not create a velocity.log file unless Avalon LogKit or Log4j are available and a runtime.log property is set. - So killing the velocity.log file is as easy as not using velocity-dep.jar and/or setting runtime.log = - I know this only sort of a B.C. concern, but it isn't really a trivial change either. - I'm of the view that Std.err is for errors (and maybe warnings), and is Std.out really redirected that often? And when it is, is that really our concern? Seems to me anyone redirecting Std.out should be prepared for surprises or least they shouldn't be critical. So, all that is to say that i currently am: -0 on removing Log4j and LogKit from the default lookup order in 1.5 -1 on punting trace/info/debug messages to Std.err +0 on punting warning messsages to Std.err -1 on putting StandardOutLogChute or kin before JdkLogChute in the lookup order +1 for tweaking this later on when we drop LogSystem support et al On 10/10/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, As you can see with the log messages, we're making some headway on a variety of Velocity issues this week. One quick item for discussion. The default logging behavior is to create a file velocity.log in the current directory. This is really quite annoying in a webapp or integrated app. One of my colleagues built a quick email routine using Velocity in a webapp. Now, I see a velocity.log file created on my Linux server in whatever directory I happened to be in when I started Tomcat! Here's the suggestion. Switch the default logging to StdErr. I'd suggested something similar in VELOCITY-403, but there was no resolution. STDERR is preferred to STDOUT so that it doesn't mess up existing log files if out is redirected. Consequence... happier web developers. Possible problem - command line apps which depend on Velocity.log being created don't see it. Any comments? WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: query - default logging behavior
Quick followup on this, then. Maybe we should leave the Avalon Log Kit out of the velocity dependency jar? My objective is to make this simpler for casual or new users. I'd think at this point the Avalon approach doesn't add a lot of value for that crowd. Those who want it can copy it into their classpath explicitly. WILL On 10/10/06, Will Glass-Husain [EMAIL PROTECTED] wrote: So - if a user deploys this without the Avalong LogKit there's no velocity.log automatically created? That seems ok to me. WILL On 10/10/06, Nathan Bubna [EMAIL PROTECTED] wrote: I haven't much time for this today, but here's my initial thoughts: - As it is, my last bought of logging upgrades made the default lookup order: LogKit, Log4j, JDK logging, and StandardOutLogChute (which sends error to Std.out and error to Std.err). This still seems appropriate for me and will already not create a velocity.log file unless Avalon LogKit or Log4j are available and a runtime.log property is set. - So killing the velocity.log file is as easy as not using velocity-dep.jar and/or setting runtime.log = - I know this only sort of a B.C. concern, but it isn't really a trivial change either. - I'm of the view that Std.err is for errors (and maybe warnings), and is Std.out really redirected that often? And when it is, is that really our concern? Seems to me anyone redirecting Std.out should be prepared for surprises or least they shouldn't be critical. So, all that is to say that i currently am: -0 on removing Log4j and LogKit from the default lookup order in 1.5 -1 on punting trace/info/debug messages to Std.err +0 on punting warning messsages to Std.err -1 on putting StandardOutLogChute or kin before JdkLogChute in the lookup order +1 for tweaking this later on when we drop LogSystem support et al On 10/10/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, As you can see with the log messages, we're making some headway on a variety of Velocity issues this week. One quick item for discussion. The default logging behavior is to create a file velocity.log in the current directory. This is really quite annoying in a webapp or integrated app. One of my colleagues built a quick email routine using Velocity in a webapp. Now, I see a velocity.log file created on my Linux server in whatever directory I happened to be in when I started Tomcat! Here's the suggestion. Switch the default logging to StdErr. I'd suggested something similar in VELOCITY-403, but there was no resolution. STDERR is preferred to STDOUT so that it doesn't mess up existing log files if out is redirected. Consequence... happier web developers. Possible problem - command line apps which depend on Velocity.log being created don't see it. Any comments? WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: query - default logging behavior
Yes, if neither LogKit (which is in velocity-dep, IIRC) nor Log4j are available to Velocity, then there is no velocity.log automatically created. Formerly, if neither were available, Velocity would panic and quit. Now it will fall back to first looking for JDK logging, and if it can't find that, then it will use the new StandardOutLogChute. On 10/10/06, Will Glass-Husain [EMAIL PROTECTED] wrote: So - if a user deploys this without the Avalong LogKit there's no velocity.log automatically created? That seems ok to me. WILL On 10/10/06, Nathan Bubna [EMAIL PROTECTED] wrote: I haven't much time for this today, but here's my initial thoughts: - As it is, my last bought of logging upgrades made the default lookup order: LogKit, Log4j, JDK logging, and StandardOutLogChute (which sends error to Std.out and error to Std.err). This still seems appropriate for me and will already not create a velocity.log file unless Avalon LogKit or Log4j are available and a runtime.log property is set. - So killing the velocity.log file is as easy as not using velocity-dep.jar and/or setting runtime.log = - I know this only sort of a B.C. concern, but it isn't really a trivial change either. - I'm of the view that Std.err is for errors (and maybe warnings), and is Std.out really redirected that often? And when it is, is that really our concern? Seems to me anyone redirecting Std.out should be prepared for surprises or least they shouldn't be critical. So, all that is to say that i currently am: -0 on removing Log4j and LogKit from the default lookup order in 1.5 -1 on punting trace/info/debug messages to Std.err +0 on punting warning messsages to Std.err -1 on putting StandardOutLogChute or kin before JdkLogChute in the lookup order +1 for tweaking this later on when we drop LogSystem support et al On 10/10/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, As you can see with the log messages, we're making some headway on a variety of Velocity issues this week. One quick item for discussion. The default logging behavior is to create a file velocity.log in the current directory. This is really quite annoying in a webapp or integrated app. One of my colleagues built a quick email routine using Velocity in a webapp. Now, I see a velocity.log file created on my Linux server in whatever directory I happened to be in when I started Tomcat! Here's the suggestion. Switch the default logging to StdErr. I'd suggested something similar in VELOCITY-403, but there was no resolution. STDERR is preferred to STDOUT so that it doesn't mess up existing log files if out is redirected. Consequence... happier web developers. Possible problem - command line apps which depend on Velocity.log being created don't see it. Any comments? WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: query - default logging behavior
+1 On 10/10/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Quick followup on this, then. Maybe we should leave the Avalon Log Kit out of the velocity dependency jar? My objective is to make this simpler for casual or new users. I'd think at this point the Avalon approach doesn't add a lot of value for that crowd. Those who want it can copy it into their classpath explicitly. WILL On 10/10/06, Will Glass-Husain [EMAIL PROTECTED] wrote: So - if a user deploys this without the Avalong LogKit there's no velocity.log automatically created? That seems ok to me. WILL On 10/10/06, Nathan Bubna [EMAIL PROTECTED] wrote: I haven't much time for this today, but here's my initial thoughts: - As it is, my last bought of logging upgrades made the default lookup order: LogKit, Log4j, JDK logging, and StandardOutLogChute (which sends error to Std.out and error to Std.err). This still seems appropriate for me and will already not create a velocity.log file unless Avalon LogKit or Log4j are available and a runtime.log property is set. - So killing the velocity.log file is as easy as not using velocity-dep.jar and/or setting runtime.log = - I know this only sort of a B.C. concern, but it isn't really a trivial change either. - I'm of the view that Std.err is for errors (and maybe warnings), and is Std.out really redirected that often? And when it is, is that really our concern? Seems to me anyone redirecting Std.out should be prepared for surprises or least they shouldn't be critical. So, all that is to say that i currently am: -0 on removing Log4j and LogKit from the default lookup order in 1.5 -1 on punting trace/info/debug messages to Std.err +0 on punting warning messsages to Std.err -1 on putting StandardOutLogChute or kin before JdkLogChute in the lookup order +1 for tweaking this later on when we drop LogSystem support et al On 10/10/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, As you can see with the log messages, we're making some headway on a variety of Velocity issues this week. One quick item for discussion. The default logging behavior is to create a file velocity.log in the current directory. This is really quite annoying in a webapp or integrated app. One of my colleagues built a quick email routine using Velocity in a webapp. Now, I see a velocity.log file created on my Linux server in whatever directory I happened to be in when I started Tomcat! Here's the suggestion. Switch the default logging to StdErr. I'd suggested something similar in VELOCITY-403, but there was no resolution. STDERR is preferred to STDOUT so that it doesn't mess up existing log files if out is redirected. Consequence... happier web developers. Possible problem - command line apps which depend on Velocity.log being created don't see it. Any comments? WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: query - default logging behavior
On 10/10/06, Nathan Bubna [EMAIL PROTECTED] wrote: On 10/10/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Nathan Bubna [EMAIL PROTECTED] writes: lookup order: LogKit, Log4j, JDK logging, and StandardOutLogChute (which sends error to Std.out and error to Std.err). This still This is IMHO not a good decision. If you want to have an application that writes to stdout, you get logging messages intermixed. I'd very much appreciate if we send all the logging to stderr. hmm. then let's punt the decision to users. we should have both StandardOut and StandardErr LogChutes, or a StandardLogChute that can be configured to direct output either way. choose whichever you wish for the default, i pretty much always manually configure logging anyway, so it won't bother me. actually, this was quick. so i took 5 minutes to write it. testing now... will check in shortly. by default all messages with level trace or higher will print to System.err - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: query - default logging behavior
Alright, Nathan! Hack away! WILL On 10/10/06, Nathan Bubna [EMAIL PROTECTED] wrote: On 10/10/06, Nathan Bubna [EMAIL PROTECTED] wrote: On 10/10/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Nathan Bubna [EMAIL PROTECTED] writes: lookup order: LogKit, Log4j, JDK logging, and StandardOutLogChute (which sends error to Std.out and error to Std.err). This still This is IMHO not a good decision. If you want to have an application that writes to stdout, you get logging messages intermixed. I'd very much appreciate if we send all the logging to stderr. hmm. then let's punt the decision to users. we should have both StandardOut and StandardErr LogChutes, or a StandardLogChute that can be configured to direct output either way. choose whichever you wish for the default, i pretty much always manually configure logging anyway, so it won't bother me. actually, this was quick. so i took 5 minutes to write it. testing now... will check in shortly. by default all messages with level trace or higher will print to System.err - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: query - default logging behavior
Hi Llewellyn! Good input. You're probably right in many cases. I did a quick scan looking for Log.error. Many of them are initialization-related errors -- perhaps those should be exceptions instead. We just moved the app-level exceptions to be RuntimeExceptions which gives us more freedom to throw exceptions without changing the API. (this was one of the obstacles in the past). I disagree a bit about reference errors -- I think we should make it optional whether or not they log a warning or stop page execution. Right now they always do the former, but I'm working on a event handler to allow the latter. I think we've addressed your patches around the uberspector in svn head at this point. WILL On 10/10/06, Llewellyn Falco [EMAIL PROTECTED] wrote: I still would like to put in my vote that sending error's to the log is an incredibly BAD idea. If something is not working, it should be LOUDLY shown as an exception. If it is working I don't really need a log. The (velocity) log should be there for velocity developers (those programming the actual velocity code) not users. I don't ever care to see tomcat's log, I care to see the things I log while in tomcat. Most of all, many many many people do not check the log at all, let alone frequently. personally I swapped out the logging uberspect over 2 years ago, in favor of code that actually worked, rather than code that didn't appear broken, but actually was. but i know the default uberspect is still the logger, i believe the TestableUberspect is still in the test branch, and a regular user is probably just confused as to why something isn't working, double or triple so if the something is in an if or for loop. Llewellyn. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: query - default logging behavior
hey, so you're sort of right about the reference errors, there are times for both logging and erroring. and those times break down to development / deploy. But as such, i still believe the default should be loud errors. because if you are going to be silent, it's best to happen when someone has explicitly stated it as such. but your right that there are times for both, and the ability to chose is important. llewellyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
