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