DDevelopment & Design

EhCache config with BeanUtils

BeanUtils allows you to set Bean properties.If you have configuration stored in a Map it’s tempting to use BeanUtils to automagically setup EhCache configuration.Sadly this class has mixed types in setters and getter and thus BeanUtils that use Introsp…

BeanUtils allows you to set Bean properties.
If you have configuration stored in a Map it’s tempting to use BeanUtils to automagically setup EhCache configuration.
Sadly this class has mixed types in setters and getter and thus BeanUtils that use Introspector behind won’t get getter and setter pairs properly. It will get only getters and thus inform you that these properties are read only: “Skipping read-only property”.

My fast solution is to use BeanUtils and have a fallback to Reflection.

public static void setProperty(Object obj, String propertyName, Object propertyValue, boolean silently) {
        try {
            PropertyDescriptor desc = PropertyUtils.getPropertyDescriptor(obj, propertyName);
            Method writeMethod = desc.getWriteMethod(); 
                 
            if (writeMethod == null) {
                writeMethod = getAlternativeWriteMethod(obj, propertyName, propertyValue.getClass());
            }
            
            if (writeMethod == null) {
                if (silently) {
                    return;
                }
                throw new IllegalArgumentException("Can't find writerMethod for " + propertyName);
            }

            if (LOG.isTraceEnabled()) {
                LOG.trace(String.format("Setting %s property of %s", propertyName, obj.getClass().getSimpleName()));
            }
            
            writeMethod.invoke(obj, propertyValue);
        } catch (IllegalAccessException | NoSuchMethodException | InvocationTargetException e) {
            throw new IllegalArgumentException("Error when setting object property.", e);
        }
    }

    private static Method getAlternativeWriteMethod(Object obj, String propertyName, Class paramClass) throws NoSuchMethodException {
        String setterMethod = "set" + propertyName.substring(0, 1).toUpperCase() + propertyName.substring(1);
        Method m; 
        if ((m = getMethod(obj, paramClass, setterMethod)) != null) {
            return m;
        }
        Class altClass = paramClass.isPrimitive() ? ClassUtils.primitiveToWrapper(paramClass) : ClassUtils.wrapperToPrimitive(paramClass);
        if ((m = getMethod(obj, altClass, setterMethod)) != null) {
            return m;
        }
        
        return null;
    }

    private static Method getMethod(Object obj, Class paramClass, String setterMethod) {

        try {
            return obj.getClass().getMethod(setterMethod, paramClass);
        } catch (NoSuchMethodException e) {
            return null;
        }
    }

I will think about PR to Configuration class but it’s complicated as EhCache 2.x is not present on GitHub.

— Previous article

All you need is docker (and fig)

Next article —

Abstract method in Enums

You May Also Like
DDevelopment & Design

Private fields and methods are not private in groovy

I used to code in Java before I met groovy. Like most of you, groovy attracted me with many enhancements. This was to my surprise to discover that method visibility in groovy is handled different than Java!

Consider this example:

class Person {
private String name
public  String surname

private Person() {}

private String signature() { "${name?.substring(0, 1)}. $surname" }

public String toString() { "I am $name $surname" }
}

How is this class interpreted with Java?

  1. Person has private constructor that cannot be accessed
  2. Field "name" is private and cannot be accessed
  3. Method signature() is private and cannot be accessed

Let's see how groovy interpretes Person:

public static void main(String[] args) {
def person = new Person()   // constructor is private - compilation error in Java
println(person.toString())

    person.@name = 'Mike'       // access name field directly - compilation error in Java
println(person.toString())

    person.name = 'John'        // there is a setter generated by groovy
println(person.toString())

    person.@surname = 'Foo'     // access surname field directly
println(person.toString())

    person.surname = 'Bar'      // access auto-generated setter
println(person.toString())

println(person.signature()) // call private method - compilation error in Java
}

I was really astonished by its output:

I am null null
I am Mike null
I am John null
I am John Foo
I am John Bar
J. Bar

As you can see, groovy does not follow visibility directives at all! It treats them as non-existing. Code compiles and executes fine. It's contrary to Java. In Java this code has several errors, pointed out in comments.

I've searched a bit on this topic and it seems that this behaviour is known since version 1.1 and there is a bug report on that: http://jira.codehaus.org/browse/GROOVY-1875. It is not resolved even with groovy 2 release. As Tim Yates mentioned in this Stackoverflow question: "It's not clear if it is a bug or by design". Groovy treats visibility keywords as a hint for a programmer.

I need to keep that lesson in mind next time I want to make some field or method private!

DDevelopment & Design

[:en] Operational problems with Zookeeper

This post is a summary of what has been presented by Kathleen Ting on StrangeLoop conference. You can watch the original here: http://www.infoq.com/presentations/Misconfiguration-ZooKeeper I've decided to put this selection here for quick reference. ...This post is a summary of what has been presented by Kathleen Ting on StrangeLoop conference. You can watch the original here: http://www.infoq.com/presentations/Misconfiguration-ZooKeeper I've decided to put this selection here for quick reference. ...