zlib.dll not found when installing the current ruby-win32

Missing libraries

zlib.dll not found

After downloading the latest win32-releases of ruby i was greeted with two error messages, SSLEAY32.dll not found and zlib.dll not found. The SSL library is kinda optional (gem, etc basicly work without it), but zlib not.

For this, the zlib library is needed, luckily there’s a native win32 port of it. So, download the latest win32 dll from zlib.net,
extract the zlib1.dll, rename it to zlib.dll and place it into the ruby bin directory.

SSLEAY32.dll not found

For SSLEAY32.dll the safest way i’ve found seems to use the version from the win32 postgresql client, which can be found here.

Just copy SSLEAY32.dll and libeay32.dll from the postgresql/bin directory into the ruby bin (or actually any other directory which is in your path)

readline.dll not found

Now you think everything is working, and start irb for the first time. Dang. readline.dll is missing. Readline win32 binaries can be found at http://gnuwin32.sourceforge.net/packages/readline.htm. Download the latest win32 build and copy the readline5.dll from the bin directory to your ruby bin directory again. Don’t forget to rename it to readline.dll.
Now everything should be working smoothly.

Posted in ruby on rails | Tagged , , | Leave a comment

Java.util.logging vs. slf4j

A bit of History

At the time the now discontinued log4j was the most commonly used logging framework for java sun decided to implement JSR 47: java.util.logging. There were a lot of discussion, but it seems not been fruitful. java.util.logging was introduced in JDK 1.4 and hasn’t changed much despite its obvious shortcomings.

The Good, The Bad and the Ugly

One of jul best selling points is the integration to J2SE 1.4. Why need another logging framework when there is one bundled with the SDK ? Unfortunately it seems the guys responsible for jul did create a similar mess like java.util.Date.

Whats good in JUL ?

  • Integration
    Everything is included in the SDK
  • Easy to get started
    Logger logger = Logger.getLogger(“de.glauche.test”);
    logger.info(“my info message”);

Whats not so good in JUL ?

    The first seems ok, but FINE, FINER, FINEST ?
  • logger.info, logger.severe etc. only accept Strings
    This is a really bad case of inconsistent API, to log an exception for example you need to use logger.log(Level.SEVERE,”Some String”, exception); Why are there no shortcuts like logger.severe(“Some String”,exception); ?
  • no parameterized logging, which can be a severe performance penality

What is Parameterized Logging ? (and why should i care for it ?)

Imagine you have lots of debug logging statements in your code:

   logger.debug("Number " + i + " has the Value:  " + entry[i]);

Here, every time the code is reached the String is build first, which can be quite time-consuming if there are many variables which need to be converted to string and concatinated. This can affect the performance of the program quite a bit, especially if it is in some inner loop.
One common solution is to wrap the debug statement with an if-clause:

if(logger.getLevel() >= Level.DEBUG) { 
   logger.debug("Number " + i + " has the Value:  " + entry[i]);

Needless to say this leads to quite messy code, is unreadable and inflexible. Fortunately there is a very underused Class in java called MessageFormat, where you can use placeholders for parameters.
So, when using something like MesageFormat, you can use: format(String pattern, Object[] arguments) for a logger. The logger could decide if the log entry needs to be constructed or not. In worst case the overhead is just a function call.

SLF4j does exactly this. It uses parameterized strings as logmessages as default. So, the above log entry in slf4j would look like this:

   logger.debug("Number {} has the Value: {}",i,entry[i]);

Unfortunately SLF4j does not use javas overloading mechanism, so you can only add two Objects, or you need to create an array of them:

   logger.debug("Value {} was inserted between {} and {}.", new Object[] {newVal, below, above});

and the Ugly ?

So, whats really ugly in JUL ?

The configuration

The default configuration resides in the JDK/lib directory (!), but can be overwritten by a command line parameter. This is very bad in the J2EE enviroment where one JDK instance can contain many independed applications.
The configuration file is rather nice and straitforward, it is easy to replace parts, or set up log levels.

but wait, there is an API to configure JUL !

There is a limited API to configure the log settings, yes. But it has some drawbacks. First, it is not so easy to replace certain parts. For example when you just want to get rid of the ugly two line default output and have all info in one clean line. With the config file it is easy, but with the API you need to implement your own Handler first.
Another big drawback is that if you configure the root logger (“”), it is still classloader dependent. If some parts of your (J2EE for example) application use different classloader mechanism, the default configuration will be used.

so how does SLF4j help ?

SLF4j is, as the name implies a simple facade for logging. It does not really log anything for itself. For the real logging you can use the build in simplelogger, JUL (if you just want some nicer API for example), logback and even Log4J. On the other hand you can also redirect log-entries from other system into SLF4j, for example Java commons Logging (JCL).
This is especailly nice, as many different libraries still use JCL or log4j.
SLF4j configures the output by the logging implementation in the classpath. Switching the real logging mechanism is as easy as replacing a jar file in your classpath.
SLF4j is fast, one does not need to write if () wrappers around the debug statments, and it has nice parameterized logging.
On the bad side, you usually need at least two additional jars as dependencies in your project, the facade and the actual logger.

There’s also a short introduction how to automaticly construct logging fields in classes with the help of guice.

Posted in java | Tagged , , , | Leave a comment

Drag & Drop with Selenium

Using Selenium for web-gui tests is really nice. You can record your workflow with the excelent selenium plugin for firefox and use them to write your own test.
The only problem seems to be Drag&Drop. The senenium runner has some drag&drop methods, but they don’t seem to work in any way. But selenium offeres mouse controll where you can simulate mouse clicks not only at an absolute position, but rather relative to a dom object. So, if your dragable <div> element has ID1 and the dropzone has ID2 you could write the following in your testrunner:


The important command for this is probably the mouseOver one, without that the richfaces d&d component for JSF would not work.

Posted in java, Testing | Tagged , , | 1 Comment

Logging with SLF4J and Guice

After getting angry at the java.util.logger once again i was thinking how to replace it with the SLF4J logger. Although Guice provides a very nice internal binding to java.util.logger, slf4j does offer a much nicer syntax.
The devil is in the detail, as allways … if you want your logger to be initialized with the current class you can’t simply inject the logger … But .. there is a nice tutorial on the guice wiki about injecting a log4j logger. SLF4J works the same.

First you need a new annotiation, like InjectLogger:

import static java.lang.annotation.ElementType.FIELD;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

public @interface InjectLogger {

next is a TypeListener, that listenes to org.slf4j.Logger classes with the annotiation InjectLogger:

import java.lang.reflect.Field;

import org.slf4j.Logger;

import com.google.inject.TypeLiteral;
import com.google.inject.spi.TypeEncounter;
import com.google.inject.spi.TypeListener;

public class Slf4jTypeListener implements TypeListener {

	public <I> void hear(TypeLiteral<I> aTypeLiteral, TypeEncounter<I> aTypeEncounter) {
		for (Field field : aTypeLiteral.getRawType().getDeclaredFields()) {
			if (field.getType() == Logger.class
	            && field.isAnnotationPresent(InjectLogger.class)) {
	        	aTypeEncounter.register(new Slf4jMembersInjector<I>(field));

Finally, you need the Slf4jMembersInjector, which does the actual injection:

import java.lang.reflect.Field;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import com.google.inject.MembersInjector;

public class Slf4jMembersInjector<T>  implements MembersInjector<T> {
	private final Field field;
    private final Logger logger;
    Slf4jMembersInjector(Field aField) {
    	field = aField;
    	logger = LoggerFactory.getLogger(field.getDeclaringClass());
	public void injectMembers(T anArg0) {
		try {
			field.set(anArg0, logger);
		} catch (IllegalAccessException e) {
			throw new RuntimeException(e);

Now you just need to bind your TypeListener inside your module class:

   bindListener(Matchers.any(), new Slf4jTypeListener());

The actual usage is simple, but instead of @Inject we need to use @InjectLogger :

    @InjectLogger Logger logger;
Posted in guice, java | Tagged , , , | 2 Comments