Change JUL agent to use the new ABI

Two things have changed, the agent port file created by the session
daemon, the name is now "agent.port". The second thing is that upon
registration, the agent needs to send its domain which is here
LTTNG_DOMAIN_JUL (val: 3).

Signed-off-by: David Goulet <dgoulet@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: remove references to trace_printf()

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
configure.ac: fix "missing jni.h" error message

DIR in --with-java-jdk=DIR must point to the JDK base
directory, not the actual JDK include directory.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Add cscope to gitignore

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Documentation: clarify event name in lttng-ust.3

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Modernize README using Markdown

This commit also:

  * adds a project description at the top
  * simplifies the steps to build/link a user
    application with LTTng-UST and provides examples
    of commands
  * updates the Package contents list

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Add M4 macros helpers to build Java programs

These M4 were taken from the autoconf archive [1].

[1] - http://www.gnu.org/software/autoconf-archive

Signed-off-by: Christian Babeux <christian.babeux@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Build the liblttng-ust-java library using the new M4 macros

The liblttng-ust-java can now be built without passing paths to
the JDK:

$ ./configure --enable-jni-interface

Signed-off-by: Christian Babeux <christian.babeux@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Refactor liblttng-ust-jul in liblttng-ust-agent

This is a major refactor of the initial implementation of the UST JUL
agent. The agent now support the log4j logging backend.

The agent can now be built in three different configurations:

1) Java agent with JUL support:

$ ./configure --enable-java-agent-jul

2) Java agent with Log4j support:

$ export CLASSPATH=$CLASSPATH:/path/to/log4j.jar
$ ./configure --enable-java-agent-log4j

3) Java agent with JUL + Log4j support

$ export CLASSPATH=$CLASSPATH:/path/to/log4j.jar
$ ./configure --enable-java-agent-all

To build the agent with log4j support, make sure that the log4j jar
is in your Java classpath.

The configure script will automatically detect the appropriate Java
binaries to use in order to build the Java agent.

The name of the agent jar file is now "liblttng-ust-agent.jar".
It will be installed in the arch-agnostic "$prefix/share/java" path
e.g: "/usr/share/java".

In order to support older applications using the "org.lttng.ust.jul"
package, a transitional package is built with the same name.

All applications should move to use the "org.lttng.ust.agent" package.

Signed-off-by: Christian Babeux <christian.babeux@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Rename public structure to avoid collisions

Since nobody raised any concern about this, I submit the patch for
merging. You can find the original discussion here:

  http://lists.lttng.org/pipermail/lttng-dev/2014-July/023364.html

(the rest of the message is identical to the RFC post)

When trying to use lttng-ust with a program that defines its own struct
tracepoint, a name collision arises and compilation fails (see example
lower).

I suggest the following renames (the problem only showed up with struct
tracepoint in my case, but let's be proactive):

 * struct tracepoint -> struct lttng_ust_tracepoint
 * struct tracepoint_probe -> struct lttng_ust_tracepoint_probe
 * struct tracepoint_dlopen -> struct lttng_ust_tracepoint_dlopen

Strictly speaking, those names are part of the public API of LTTng, so I
understand that it would be a felony to rename it, since it breaks the
holy API. However, those structures are only used through some macros,
and I am not aware of any sensible use case where a user of lttng-ust
would directly reference those structures. Therefore, it should not break
any existing code. If you do have such a use case, where it would break
your code, please jump in the discussion.

This should not break any application instrumented and built before the
change. Tested by building "hello" before and tracing it after the
change.

Here is an example of error due to the name collision. This is when
building gdb, which I try to instrument with lttng-ust.

In file included from /usr/local/include/lttng/tracepoint.h:28:0,
                 from ust_tracepoints.h:15,
                 from inf-ptrace.c:38:
/usr/local/include/lttng/tracepoint-types.h:32:8: error: redefinition of
‘struct tracepoint’
 struct tracepoint {
        ^
In file included from inferior.h:37:0,
                 from inf-ptrace.c:22:
breakpoint.h:817:8: note: originally defined here
 struct tracepoint
        ^
Makefile:1088: recipe for target 'inf-ptrace.o' failed
make: *** [inf-ptrace.o] Error 1

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: Wrong CLASSPATH when building liblttng-ust-java-agent oot

Signed-off-by: Christian Babeux <christian.babeux@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: Wrong CLASSPATH when building liblttng-ust-java oot

Signed-off-by: Christian Babeux <christian.babeux@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cleanup: Remove the no longer needed liblttng-ust-jul folder

Signed-off-by: Christian Babeux <christian.babeux@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: Abort loading log4j agent classes when detected log4j version is too old

The Java Log4j agent rely on the getTimeStamp() method that was
introduced in log4j 1.2.15. This fix implement a runtime detection of
the log4j library capabilities and abort the loading of the relevant
agent classes if the version used is too old.

Thus, log4j tracing will be deactivated on older version of the
library.

Signed-off-by: Christian Babeux <christian.babeux@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: preserve example files' timestamps when copying

This fixes an issue where examples were always being rebuilt
when performing an out of tree build since the examples were
being copied to the build directory with a timestamp more
recent than the already-built example objects.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Add missing file to gitignore

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Version 2.6.0-rc1

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Update version name

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Add Python agent support

This adds a new library in this repository being the
liblttng-ust-python-agent. It contains the Python agent and a library
for the tracepoints used by the agent.

To enable the python agent, use --enable-python-agent to build it.

This new agent is bound to the LTTng python domain in lttng-tools which
implements the -p,--python option for agent's command.

It works and tested for python 2.7.x and 3.x

Signed-off-by: David Goulet <dgoulet@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fix: Try loading classes using the thread context class loader

LTTngAgent should load classes using the current thread context's
class loader and then try using the system class loader if a
ClassNotFoundException is thrown.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>