I vote for 1 logging configuration (ERROR only). Why do we want different logging in Travis vs local? If you are working on a specific component and need more verbose logging, temporarily change the log level to INFO for that component. If we get the logging in shape this will be easy to do.
On Wed, Nov 2, 2016 at 1:18 PM, Otto Fowler <[email protected]> wrote: > On Fri, Oct 28, 2016 at 3:13 PM > <http://airmail.calendar/2016-10-28%2015:13:00%20EDT>, David Lyle < > [email protected]> wrote: > > > I think you noticed the main problem with turning logging off entirely. > > > > I'd be inclined to have two files: one which defaults to INFO and another > > that defaults to ERROR for Travis. We can give a > -Dlog4j.configuration=file:log4j.config.set.to.ERROR.only > > for travis, which I think Otto suggested. > > So - > * one jira to fix the component shutdowns ( I’ll take a stab unless you are > already on it ) > * one jira to have travis run with a second configuration ( be it literally > a second file or something else ) set to error only > > > > > On November 2, 2016 at 13:51:28, Casey Stella ([email protected]) wrote: > > What would be in the two different logging properties? > > On Wed, Nov 2, 2016 at 1:45 PM, Otto Fowler <[email protected]> > wrote: > > > What about having two logging configurations? One just for travis, and > > one pretty much what there is now ( the teardown stuff still has to be > > sorted out ). Maybe Travis can be scripted to put the right logging > > properties files in place? > > > > > > On November 2, 2016 at 12:42:09, Casey Stella ([email protected]) > wrote: > > > > I haven't seen a JIRA about this yet. IMHO, I think a good first-pass > > would be: > > * We have a lot of ERROR level logging that happens because during > teardown > > of the in memory components that could be fixed by tearing down > components > > in the right order (possibly). > > * Teardown in some of our integration tests don't seem to get called if > the > > tests fail, this causes cascading errors to happen ( the next test won't > > start because it can't start the components), so ensuring teardown > happens > > in a finally block would be good > > * If there are chatty components that are inappropriately logging, we can > > adjust the logging level on a per-package basis. Tender balance between > > suppressing valuable output and chattiness would ahve to be made (and > > probably discussed as part of a JIRA). > > > > In retrospect, after considering this after the previous discussion on > the > > dev list, I would not be in favor of logging to a file. It is important > to > > see those logs on the travis output to help with quick-debugging help and > > we'd be setting ourselves up to be non-standard as well. I'd rather see a > > more directed and surgical effort. > > > > That's just my $0.02, though. I'd welcome a JIRA (or multiple JIRAs) to > > tackle logging. > > > > On Wed, Nov 2, 2016 at 12:33 PM, Otto Fowler <[email protected]> > > wrote: > > > > > Did a jira for this actually get created? I would be willing to help > work > > > on getting the logs setup for what they need to be for travis and for > > > local. Did we settle on an approach? Is there work ongoing that could > use > > > some dev or testing help? > > > > > > > >
