On 05/10/2018 17:14, Rafael Winterhalter wrote:
:
To make sure that this is considered properly, I want to lay out a
simple but common instrumentation use case once again to show how the
current API suggestion is too limited. Consider a basic
instrumentation for monitoring the runtime of a business transaction
that spans to classes. I keep it fairly simple but this is not too far
off to how some monitoring tools are actually implemented.
This discussion always comes to down to what the Instrumentation API is
intended for. Some of these apparently "simple" cases aren't really
simple as they are trying to use Instrumentation API in ways that were
never intended. As we explained in the discussions on
serviceability-dev, the intention was to support cases where code is
instrumented with calls into agent provided supporting classes and
reduce any dependence that can lead to circularity issues. It maybe that
the current appendToXXXSearch is too limited as it doesn't help with
cases where the agent is spinning the supporting classes at run-time, in
which case there may be a useful discussion there. The
serviceability-dev list is the right place for that.
-Alan
