Working with the JWeb1TSearcher, I received tons of warning messages that some specific token could not be found:

As I did not care about this warning, I wanted to turn it off. Looking at the dependencies of the enclosing artifact com.googlecode.jweb1t, I learned that JWeb1T library uses the Apache Commons Logging library. Therefore, in order to disable the logging (programmatically) for the JWeb1TSearcher class we can use the following code snippet:

Only log messages of level ERROR or above will be logged now.

Links

  • [1] Dependencies of com.googlecode.jweb1t:com.googlecode.jweb1t
  • [2] Apache Commons Logging guide

Even though it is not a good implementation style some libraries print information to standard output or standard error. If you have no influence on that, this can be annoying and may conceal important information. A stackoverflow question deals with this problem and I find the following solution the most elegant one:

Instead of ignoring the output you may want to print it to a log file for further inspection in case something goes wrong. In this case, do not define your own stream but use an instance of FileOutputStream:

Analogously,  System.setErr(PrintStream) may be used for setting the new standard output stream.

Links

  • [1] stackoverflow question which pointed me at this

By default, Maven does not compile any debug information into an artifact. This is (sometimes) reasonable when you publish libraries which you do not want to reveal too much information about. For personal use, however, I prefer to be able to have a look at the full stack trace. Another benefit of adding debugging information is that you can read the original parameter names of methods.

As debug information is added at compile time, the Maven Compiler plugin is responsible for managing this kind of information:

Links

  • [1] Reference of Maven Compiler plugin

Depending on your version of Maven, the default Java version assumed by the compiler plugin may be quite old, even as old as not to recognize annotations. When working with annotations you will get compiler errors such as the following:

Solution 1

You can configure Maven to accept (-source argument for the Java compiler) and produce byte code for (-target compiler argument) a certain Java version as follows:

Solution 2

It is even simpler to use properties:

Links

  • [1] Reference of Maven Compiler plugin

Java Standard Logging

This article describes a template for using and configuring logging in a Java application. Even without any configuration we obtain a logger by calling the static method Logger.getLogger(String name). By convention, I use the class name of the class whose member the logger is as name:

The default logging behavior is to log all events to standard error, however we can easily redirect/mirror our logging to a log file. The necessary configuration is outsourced in a properties file (often called logging.properties, Download):

In order to make this configuration file knwon to our application, we need to request the LogManager to read the configuration file:

You can test your logger as follows:

For other logging facilities such as Log4j, there exist mechanisms which allow for auto-discovering the logging properties.

I have uploaded an example application as Maven project on GitHub.

Log4j

Log4j will use a configuration properties file if it is called log4j.properties and can be found on the classpath. What follows is a simple template configuration that makes Log4j log to console:

The patterns used by Log4j have a different notations than the format property. The output format of each line is determined by the PatternLayout

Links

  • [1] Sample Project hosted on GitHub

Args4j is an easy-to-use and – for most cases – sufficiently powerful library for processing program options. An important feature is that the mapping from program option to java fields is managed via @Option and @Argument annotations. Moreover, support for “trailing” program options (normally used for input files) and multi-valued options is perfectly simple to set up.

The following small program may serve as a template for using Args4j (Download):

Maven Dependency

Links

  • [1] Args4j project site
  • [2] Example code on GitHub

The toolkit uimaFIT allows you to design annotation types in the so-called Component Descriptor Editor, save the descriptor as XML and generate the corresponding Java classes. When you run an analysis engine that makes use of these annotations uimaFit checks whether it finds the type system descriptor XML file on the classpath. In certain circumstances, it may happen that it falls short of finding this file and will abort with the following error message:

In this case you need to explicitly point uimaFIT to the location of your type descriptor file. For this to be done, there exist two different ways.

Solution via VM argument

As a quick and dirty solution you add the following VM argument which in Eclipse is configured in the Launch Configuration dialog

In my case, I stored the XML file in src/main/resources/desc/types/TypeSystem.xml where src/main/resources is set to be a source folder in Eclipse (Maven project layout).

Solution via types.txt (suggested)

The issue with the solution above is that your code will break if other people try to execute it without knowing about the VM parameter. There exists a more stable way to solve this issue. uimaFIT looks into the file

  • <classpath>/META-INF/org.uimafit/types.txt  (for uimaFit until 1.4.x, still supported by the uimafit-legacy-support package)
  • <classpath>/META-INF/org.apache.uima.fit/types.txt (for uimaFit 2.0.0 and above)

in order to find out where to search for the XML type descriptor files (In a Maven context META-INF should be located in src/main/resources). Each line in this types.txt file describes one search pattern. In our example, types.txt should contain one line:

Links

  • [1] uimaFit Guide and Reference – 8.1. Making types auto-detectable
  • [2] DKPro tutorial (UIMA part): Type System Auto-Discovery (Slide 37)
  • [3] TypeDescriptorDetection

When you use AbstractTransactionalJUnit4SpringContextTests for database testing, you can easily access the database using a SimpleJdbcTemplate which is autowired with a DataSource bean. If, however, Spring finds more than one such data source on the classpath, it will fail to run the test. In the following error message, there are two candidates for autowiring.

The solution is to override the setDataSource method and to explicitly provide the DataSource instance to use (by bean name):

The Apache Commons IO library offers a utility method which allows you to read a file directly to a string in just one line of code. As test case, I use the following, UTF-8 encoded file:

The Java code below demonstrates the use of the two methods readFileToString and readLines, both with and without the explicit encoding being given. I deliberately use the wrong encoding for reading the file in order to show the effect.

Output:

Maven Dependency

(Check current version here)

Links

The following code showcases how we can instantiate collections inside application context files in Spring. I suppose we want to use a class DummyContainer as a bean and we instantiate the following collection type properties of this class (assume the appropriate setters are given). The class MyBean is defined elsewhere and its actual properties do not matter here. We use two instances of the class in order to demonstrate reference values and inplace bean definitions:

  • java.util.List<Object> aList;
    • Content:  [“Hello World”, new Double(1.3), new MyBean(), new MyBean()]
    • XML element: <list/>
  • java.util.Map<String, Object> aMap;
    • Content: [[“Item 1”, “Hello World”],[“Item 2”, new Double(1.3)],[“Item 3”, new MyBean()],[“Item 4”, new MyBean()]]
    • XML element: <map/> and <entry/>
  • java.util.Properties properties;
    • Content: [[“Prop 1”, “Value 1”]]
    • XML element: <props/> and <prop/>
  • java.util.Set<Object> aSet;
    • Content: [“Hello World”, new Float(1.3), new MyBean(), new MyBean()]
    • XML element: <set/>

This is how the context  file looks like:

Links

  • Spring 3.1.x Reference – Section 4.4.2.4 Collections
  • mkyong‘s summary of the collection elements (actually nicer than my entry here :-))