Raman Gupta

@josegonzalez Well, it does get us part of the way there -- it lets us explicitly label all the containers that we wan to include. But unfortunately, now we have...

I think this is the situation: * Label-based exclude (in master now) * Label-based include (pending pull #222 ) * Environment-based exclude (in master now) * Environment-based include (**missing?**) *...

> Mind making a pull request? I wouldn't, though I've never written any Go code before and for some reason I find the syntax somewhat opaque and unreadable (`:=`? what...

@michaelshobbs @dcassiero was not the original reporter. Not sure why your comment addresses his use case. Unless there is a solution for my use case, not sure why this was...

@michaelshobbs Not sure when I'd get around to it, but what did you think of my proposed approach outlined above? https://github.com/gliderlabs/logspout/issues/258#issuecomment-276513122

> Generally speaking, I'm pretty averse to complex rules like you outlined. Agreed. The primary complexity comes from trying to maintain backward compatibility while also adding function. If you're ok...

@michaelshobbs Here is a proposed simplification. Everything is controlled by filters, but filters can refer to labels and environment variables, and be negated. In detail: For a container to be...

Same problem here with kotlin/js tests.

I have this issue too -- when I updated to the latest kroto-plus, I lost all logging of exceptions on the server-side, because we removed our custom exception handling code...

@marcoferrer My previous exception logging was done via wrapping all my implementations in a function, similar to as shown above (except it passes through StatusExceptions unlogged, as these are "expected"...