Refactor Java agent to let applications manage the log handlers
authorAlexandre Montplaisir <alexmonthy@efficios.com>
Wed, 22 Jul 2015 02:56:15 +0000 (22:56 -0400)
committerMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Wed, 29 Jul 2015 01:32:17 +0000 (21:32 -0400)
Major refactoring of the UST Java agent and its JUL and log4j
logging facilities.

Split up the big LTTngAgent class into two separate agent
singletons, one for JUL and one for log4j.
The large parts of common code remain in the -common package
in AbstractLttngAgent, with the API-specific implementations
in their respective -jul or -log4j package.
This removes the need for circular-dependencies (which were
worked around using reflection) between the common and the
other packages.

The applications are now expected to instantiate their
JUL Handler or log4j LogAppender themselves, and to attach
them to corresponding Logger objects. The LttngLogHandler and
LttngLogAppender classes are now made public to allow this.

Agents are now spawned automatically on demand, as Handler
objects are created. Once the last handler/appender is
close()'d, the agent is disposed as well. This reduces the
number of threads and socket connections to the minimum that
is necessary.

The two separate tracepoints in the JNI libraries, "tracepointS"
and "tracepointU", are now merged into one. Events sent to
either the root or user session daemon will use the same call.

The LTTngAgent.getLTTngAgent() API is kept for compatibility
with applications using it, but now marked @Deprecated. The
functionality underneath was re-implemented using the new
classes, but the behaviour should be kept the same.

Signed-off-by: Alexandre Montplaisir <alexmonthy@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

No differences found
This page took 0.027563 seconds and 4 git commands to generate.