Adrian Cole

Also, while the title includes a decision about whether to also carry-forward p6spy, interest in datasource-proxy is independent. If you just want to express you want datasource-proxy support, put a...

I've added a feature request to allow your 2.x codeline to be 1.6 bytecode. We can discuss there, and crazy as it sounds, we still have folks running old runtimes...

So there was a question about feedback and things leading to this issue. I won't mention routine glitches and things. I will answer other comments independently. I'm not sure I...

@gavlyukovskiy and others.. one thing I would like to have is a clear path for folks to decorate our default database policy. For example, sometimes people want more data than...

@ewhauser thanks for piping in, especially highlighting the "no dependency injection" story as I presume that's what you meant by not spring (ex we do sometimes get feedback on dagger...

One feedback I would give (ironically from a project that is wordplay on the word dapper :P) is that p6spy is a terrible name. No one knows it has anything...

to pre-empt the question, we use the same names of the libraries in our artifact names, so `brave-instrumentation-datasource-proxy` or `brave-instrumentation-p6spy`. We do this because the primary concern is instrumenting the...

FYI I've heard several people want to name something brave-instrumentation-jdbc (not just originally @ewhauser which I admit to resisting). If we do formalize something with such a name we are...

> > If the main problem to to solve on naming is discoverability, I'd probably > opt for brave-instrumentation-jdbc-library. Although more verbose, it has > the nice qualities of being...

I have possibly a terrible idea to solve the discovery problem. we make brave-instrumentation-jdbc we publish it to maven central. inside that jar is a copy of a README that...