Help w/ log4j on roboRIO

Technical Java
1

Hi -

I wanted to move to a better logging mechanism than System.out.println, and decided to go with log4j. But I am having some problems getting it running … I see a couple of posts about it here, but nothing has helped with making it work on this year’s robot.

I tried to go with the ‘new’ version 2, but there appear to be dependencies that I don’t want to deal with - and previous experience with the older version 1 says it will work for our needs.

I modified the userLibs entry in build.properties to get the third party libraries incorporated, and that seems to work - if I untar the FRCUserProgram.jar after a build, there are a bunch of classes in there, which I assume is a correct repackaging of the log4j-1.2.17.jar.

The problem is the configuration file - log4j.properties. I can’t figure out how to get it into the jar file so it shows up for use. I tried looking through the hierarchy of build.xml files for Ant in the WPILib stuff - but don’t know enough about Ant to find out how.

So I decided to just copy it over to the lvuser home directory, since that seems to be the default classpath for the execution of the script that actually runs the built jar file. But I get log4j warnings about the initialization process; including some exceptions about a Java class not found for “java/beans/IntrospectionException” - which I assume is because the version of Java we run on the roboRIO is missing what a ‘normal’ SDK has.

At this point my log4j.properties is pretty basic - just a simple console appender for output. So I’m assuming that isn’t the problem.

If I use the BasicConfigurator, I still get the warning and the NoClassDefFoundException, but it sort of runs - as I get my formatted log messages to the NetConsole … I just can’t control the output.

If someone who has gotten this working could give me some help, I would greatly appreciate it!

Thanks in advance!
Stu

2

The Ant scripts we have don’t include anything but .class files in the jar it builds. That’s fixable, look in the “jar” task of wherever/wpilib/java/current/ant/build.xml, and we see:

<fileset dir="${build.dir}" includes="**/*.class"/>

Adding a line like this:

<fileset dir="${src.dir}" includes="**/*.properties"/>

should get your file into the jar, but will be fragile (you’ll need to customize every machine you deploy from, and your change will get lost everytime you take an update of the Eclipse plugins). I put a feature request in for this to get made part of wpilib.

I think you touched on what may be a show stopper: as I recall, the runtime configuration we have is missing a lot of stuff necessary to make log4j basic configuration work (missing introspection and some of the XML apis, as I recall). Try it, if it works, let us know!

You may need to go to full programmatic configuration to use log4j.

You may want to consider using java.util.logging; it’ll work out of the box. I don’t like the API, but it’s a low hassle way to get what you want. You can programmatically config it pretty easily. We did it last year: take a look at our last year’s code https://github.com/FRC3620/FRC3620_2015_AverageJava
(look at the EventLogger class), you are welcome to the relevant bits.

We actually didn’t even use the j.u.l API, just the logging framework, we used slf4j for the logging API, so we need the slf4j-api jar. The build.properties that make that happen in 2015 was uglier than it needs to be anymore. Use the new way(‘userLibs’).

We ended up configuring the appenders (well, handlers in j.u.l) once (we sent INFO on up to the console, and everything went to log file on the roboRIO). We set the logging level for each logger as created, so every command/subsystem that creates a logger sets the level of logging it wants at the time it does the creation. Not the way I like to do things, but it kept programmers from dancing on each other’s setting in a master logging config.

3

I don’t think /home/lvuser is on the class path: the command used to start java is

 env LD_LIBRARY_PATH=/usr/local/frc/rpath-lib/ /usr/local/frc/bin/netconsole-host /usr/local/frc/JRE/bin/java -jar /home/lvuser/FRCUserProgram.jar
4

That’s exactly correct: we generate a JRE using profile version 2 of the embedded JRE creator. It does not have everything in the standard JDK, including the Java Beans stuff. If you want to use it, you’ll have to generate your own JRE with the appropriate packages available.

5