Java EE6 in the Cloud – Getting started with Red Hat Openshift

OpenShift For a while now I’m looking into ‘the cloud’. Looking into its features, what it can do, why we should switch to ‘ the cloud’, going to talks, talking to people like @maartenballiauw, who is a cloud specialist at RealDolmen. I’ve already deployed an application on google app engine (for java) and I really liked the experience. Some new concepts come into play like distributed data and so on.
But in the recent chain of events, being more interested in the future of java EE, I looked into OpenShift.
OpenShift is a PaaS offerd by Red Hat. The basic idea is to run Java EE 6 in the cloud and that is exactly what we want to do. I’m using Ubuntu for this, so all my commands are based upon the Ubuntu distro. Be sure to register for an account on openshift.redhat.com, you will need it to create a domain and application.

Starting of we have to install ruby gems. The ruby gems are the interface to manage our cloud domain. So first we install the gems.

$ sudo apt-get install git ruby rubygems ruby1.8-dev

We need git to checkout the code, the ruby packages is to install the gems. Now we install the gems.

$ sudo gem install rhc

The rhc (red hat cloud I presume) is the base for all the commands that will be used to manipulate our openshift domain. So first we need to create a domain.
The gems are standard deployed installed in the /var/lib/gems/1.8/gems/bin folder. We best add it to our $PATH variable for easy access. Now everything is ready to start working with openshift.

Now we want to create a domain. The domain is your work directory on OpenShift. Choose something unique and you will be able to access your applications via http://projectname-domainname.rhcloud.com. To create your domain we need the ‘rhc-create-domain’ command.

$ ./rhc-create-domain -n domainname -l loginid

Now you will be promted for you password, just type it and you are done. Your domain is created.
Your domain is setup, we now want to create an application.

$ ./rhc-create-app -a applicationName -t jbossas-7.0

The -t parameter indicates we will be running the application on a jbossas-7.0. The cool thing about creating an application on OpenShift is that we now have a fully setup git repository. When we push, the application is pushed to OpenShift.
To start of I forked the seambooking example on github (https://github.com/openshift/seambooking-example). I did not really need to fork it, but it offers a good basic setup for OpenShift project. Once I’ve added the code to my OpenShift git repository, I can simply do a git push.

$ git push

The sample app is running, running in the cloud…

More information on http://openshift.redhat.com and https://github.com/openshift/seambooking-example

Java EE6 Decorators, advanced usage

After I published my first article about Java EE6 decorators, it got some attention on dzone. I got some comments telling me the example isn’t exposing the true power of the decorator feature.
The first thing I did not mention in my previous post is that we can combine a number of decorators and choose the order we want them executed.
If you have a use case for it, you can easily define 2 decorators, by just defining them in the beans.xml file like this.

    <decorators>
        <class>be.styledideas.blog.decorator.HighDecorator</class>
        <class>be.styledideas.blog.decorator.LowDecorator</class>
    </decorators>

So when we call our decorated class, we get the highdecorator entry, low decorator entry, actual decorated class, low decorator exit, highdecorator exit. So the decorator sequence in the file does matter.
The second feature is more compelling than the first, it exposes the true power of the Decorator feature in java EE6. That is the ability to combine it with CDI annotations. As example I’ll use an Social media feed processor.
So I have created an interface

public interface SocialFeedProcessor {
    Feed process(String feed);
}

and provided 2 implementations, twitter and google+

public class TwitterFeedProcessor implements SocialFeedProcessor{

    @Override
    public Feed process(String feed) {
        System.out.println("processing this twitter feed");
        // processing logics
        return new Feed(feed);
    }
    
}
public class GooglePlusFeedProcessor implements SocialFeedProcessor {

    @Override
    public Feed process(String feed) {
        System.out.println("processing this google+ feed");
        // processing logics
        return new Feed(feed);
    }
    
}

I’ll annotate these 2 beans by a custom Qualifier as described here

@javax.inject.Qualifier
@java.lang.annotation.Retention(RUNTIME)
@java.lang.annotation.Target({FIELD, PARAMETER, TYPE})
@java.lang.annotation.Documented
public @interface FeedProcessor {
}

and I annotate my 2 processors with it.

@FeedProcessor
public class TwitterFeedProcessor implements SocialFeedProcessor{

    @Override
    public Feed process(String feed) {
        System.out.println("processing this twitter feed");
        // processing logics
        return new Feed(feed);
    }
    
}
@FeedProcessor
public class GooglePlusFeedProcessor implements SocialFeedProcessor {

    @Override
    public Feed process(String feed) {
        System.out.println("processing this google+ feed");
        // processing logics
        return new Feed(feed);
    }
    
}

Nothing really special, but now when we write our decorator we use the power of CDI to only decorate the classes with the @FeedProcessor annotation.

@Decorator
public class SocialFeedDecorator implements SocialFeedProcessor {
    @Delegate
    private @FeedProcessor SocialFeedProcessor processor;

    @Override
    public Feed process(String feed) {
        System.out.println("our decorator is decorating");
        return processor.process(feed);
    }
}

the only thing that is left is registering our decorator in our beans.xml

    <decorators>
        <class>be.styledideas.blog.decorator.SocialFeedDecorator</class>
    </decorators>

By using the annotation, we automatically decorate all our implementations of the SocialfeedProcessor with this decorator. When we add an extra implementation of the SocialFeedProcessor without the annotation, the bean will not be decorated.

Return the same object that was given as parameter with EasyMock

Every time I have to use EasyMock, I get annoyed. For those who don’t know EasyMock, it is a mocking framework that allows you to mock certain pieces of code when doing unit testing. In my humble opinion, there are better ways to create mocks in unit test, but at my current project I’m using EasyMock.
There are 2 reason, the first is the lack of more advanced mocking tutorials on the interwebs. When I go looking for a specific solution, I never really find what I need.
The second reason is a more justified one, but still personal. I alway forget how the API of EasyMock works, it is not self explanatory, a former colleague of mine even once called it DifficultMock…
I’m not going to rant about my lack of love for this java mocking framework, instead I’m going to offer a solution.
So basically, what I was trying to do, was to capture an argument I give to a method and return the same object. We could take the JPA method EntityManager.merge(T entity) method as example. We take an unattached object and attach it. The result is our attached object. Seems releasable to include in a test.
So I want to capture my argument and return it. After playing a bit with the API I got this

EntityManager entityManager = EasyMock.createNiceMock(EntityManager.class);
final Capture<Entity> capture = new Capture<Entity>();
EasyMock.expect(entityManager.merge(EasyMock.capture(capture))).andReturn(capture.getValue());
replay(entityManager);
executeTest();

This compiled fine, but gave an error at runtime, saying

Nothing captured yet

So I’m not able to define my andReturn method, because it already tries get the value of my captured object. Instead of giving my andReturn method a value, I have to give it a function, a closure. Since Java doesn’t have closures (yet), I’m forced to use a poor mans closure.
EasyMock supplies an Interface and a method we can use here. The IAnwser interface and we replace the andReturn method by the andAnwser method.
By creating an annonymous implementation of this interface, we create a one-function class, like a normal closure.

final EntityManager entityManager = EasyMock.createNiceMock(EntityManager.class);
final Capture<Entity> capture = new Capture<Entity>();
EasyMock.expect(entityManager.merge(EasyMock.capture(capture))).andAnswer(new IAnswer<Entity>() {

    public Entity answer() throws Throwable {
        return capture.getValue();
    }
});
replay(entityManager);

Automatic Deadlock retry Aspect with Spring and JPA/Hibernate

I’m currently working on a project that is converted from being a Mainframe application, to a Java web/batch application. We don’t ‘big bang’ into production, so the Mainframe and the Java code will work next to each other for a fairly amount of time. Since we have multiple batch processes and many simultaneous users, we start seeing deadlock errors in certain parts of the application. Some specific parts have to take a pessimistic lock, this is where it goes wrong.
Since a deadlock is an error that can be solved by repeating the action, we decide to build in a retry mechanism to restart the transaction if it got rolled back.
I started of with creating an Annotation. This annotation will mark the entry point that we want to retry in case of a deadlock.

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface DeadLockRetry {
    /**
     * Retry count. default value 3
     */
    int retryCount() default 3;
}

The retry count is a value you can supply together with your annotation, so you can specify the number of times we want to retry our operation.
Using AOP we can pick up this annotation an let us surround the method call with a retry mechanism.

@Around(value = "@annotation(deadLockRetry)", argNames = "deadLockRetry")

So lets view the aspect, we start with adding an @Aspect annotation on top of our class, this way it is configured to be an Aspect.
We also want to implement the Ordered interface. This interface lets us order our aspect. We need this to surround our Transactional aspect. If we don’t surround our Transaction, we will never be able to retry in a new transaction, we would be working in the same (marked as rollback only) transaction.
The rest of the code is pretty straight forward. We create a loop where we loop until we have more retries than we should have. Inside that loop we proceed our ProceedingJoinPoint and catch the PersistenceException that JPA would throw when a deadlock would occur. Inside the catch block we check if the error code is a deadlock error code.
Off course we could not directly configure the database specific error codes inside our aspect, so I’ve created an interface.

/**
 * Interface that marks a dialect aware of certain error codes. When you have to
 * do a low level check of the exception you are trying to handle, you can
 * implement this in this interface, so you can encapsulate the specific error
 * codes for the specific dialects.
 * 
 * @author Jelle Victoor
 * @version 05-jul-2011
 */
public interface ErrorCodeAware {
    Set<Integer> getDeadlockErrorCodes();
}

We already have custom hibernate dialects for our database and database to be, so this let me configure the error codes in the Dialect implementations. It was a bit tricky to get the current dialect. I injected the persistence unit, since we are outside a transaction, and made some casts to get my dialect. The alternative was to use a custom implementation of the ErrorCodeAware interface, not using the dialects. We could inject the needed ErrorCodeAware implementation based on our application context. This added another database specific injection, which added another point of configuration. This is why I chose to store it in our custom dialect.

private Dialect getDialect() {
        final SessionFactory sessionFactory = ((HibernateEntityManagerFactory) emf).getSessionFactory();
        return ((SessionFactoryImplementor) sessionFactory).getDialect();
    }

The only thing left is to configure the aspect, mind the order of the transaction manager and the retry aspect

	<tx:annotation-driven order="100" transaction-manager="transactionManager" />
	<bean id="deadLockRetryAspect" class="DeadLockRetryAspect">
		<property name="order" value="99" />
	</bean>

Now when I have a deadlock exception, and I’ve added this annotation, the transaction will rollback and will be reexecuted.

/**
 * This Aspect will cause methods to retry if there is a notion of a deadlock.
 * 
 * <emf>Note that the aspect implements the Ordered interface so we can set the
 * precedence of the aspect higher than the transaction advice (we want a fresh
 * transaction each time we retry).</emf>
 * 
 * @author Jelle Victoor
 * @version 04-jul-2011 handles deadlocks
 */
@Aspect
public class DeadLockRetryAspect implements Ordered {
    private static final Logger LOGGER = LoggerFactory.getLogger(DeadLockRetryAspect.class);
    private int order = -1;
    @PersistenceUnit
    private EntityManagerFactory emf;

    /**
     * Deadlock retry. The aspect applies to every service method with the
     * annotation {@link DeadLockRetry}
     * 
     * @param pjp
     *            the joinpoint
     * @param deadLockRetry
     *            the concurrency retry
     * @return
     * 
     * @throws Throwable
     *             the throwable
     */
    @Around(value = "@annotation(deadLockRetry)", argNames = "deadLockRetry")
    public Object concurrencyRetry(final ProceedingJoinPoint pjp, final DeadLockRetry deadLockRetry) throws Throwable {
        final Integer retryCount = deadLockRetry.retryCount();
        Integer deadlockCounter = 0;
        Object result = null;
        while (deadlockCounter < retryCount) {
            try {
                result = pjp.proceed();
                break;
            } catch (final PersistenceException exception) {
                deadlockCounter = handleException(exception, deadlockCounter, retryCount);
            }
        }
        return result;
    }

    /**
     * handles the persistence exception. Performs checks to see if the
     * exception is a deadlock and check the retry count.
     * 
     * @param exception
     *            the persistence exception that could be a deadlock
     * @param deadlockCounter
     *            the counter of occured deadlocks
     * @param retryCount
     *            the max retry count
     * @return the deadlockCounter that is incremented
     */
    private Integer handleException(final PersistenceException exception, Integer deadlockCounter, final Integer retryCount) {
        if (isDeadlock(exception)) {
            deadlockCounter++;
            LOGGER.error("Deadlocked ", exception.getMessage());
            if (deadlockCounter == (retryCount - 1)) {
                throw exception;
            }
        } else {
            throw exception;
        }
        return deadlockCounter;
    }

    /**
     * check if the exception is a deadlock error.
     * 
     * @param exception
     *            the persitence error
     * @return is a deadlock error
     */
    private Boolean isDeadlock(final PersistenceException exception) {
        Boolean isDeadlock = Boolean.FALSE;
        final Dialect dialect = getDialect();
        if (dialect instanceof ErrorCodeAware && exception.getCause() instanceof GenericJDBCException) {
            if (((ErrorCodeAware) dialect).getDeadlockErrorCodes().contains(getSQLErrorCode(exception))) {
                isDeadlock = Boolean.TRUE;
            }
        }
        return isDeadlock;
    }

    /**
     * Returns the currently used dialect
     * 
     * @return the dialect
     */
    private Dialect getDialect() {
        final SessionFactory sessionFactory = ((HibernateEntityManagerFactory) emf).getSessionFactory();
        return ((SessionFactoryImplementor) sessionFactory).getDialect();
    }

    /**
     * extracts the low level sql error code from the
     * {@link PersistenceException}
     * 
     * @param exception
     *            the persistence exception
     * @return the low level sql error code
     */
    private int getSQLErrorCode(final PersistenceException exception) {
        return ((GenericJDBCException) exception.getCause()).getSQLException().getErrorCode();
    }

    /** {@inheritDoc} */
    public int getOrder() {
        return order;
    }

    /**
     * Sets the order.
     * 
     * @param order
     *            the order to set
     */
    public void setOrder(final int order) {
        this.order = order;
    }
}

JPA 2, The Access annotation

JPA 1 has a strict rule about what the access when defining your meta annotations (you database to java mapping). In jpa 1 the standard was the way the ID was mapped. So when you placed your @Id or @EmbeddedId annotation (which is mandatory for every bean annotated with the @Entity annotation) on a field, all access will happen through the fields, when you apply it on the getter/setter methods, all fields will use the getter/setter methods.
JPA 2 adds some extra flexibility here. When you want your fields to be access through the fields, but there is one field that you want to modify when setting or getting, you can provide the @Access annotation.
This annotation defines the path of the persistence provider. It basicly has 2 modes

AccessType.FIELD, AccessType.PROPERTY;

You first have to annotate your Entity to set the base access mode, so the @Id rule is overruled.

@Entity
@Access(AccessType.FIELD)
public class Car implements Serializable {
// some fields, getters and setters
}

We have now configured the Pojo to use the fields unless we define it otherways.
by placing the @Access annotation on top of a getter (not setter, this will give an error that the annotation only should be applied on no-param methods), you tell it should use the getter/setter instead of direct access to the field.

@Access(AccessType.PROPERTY)
    public Brand getBrand() {
        return brand;
    }

    public void setBrand(Brand brand) {
        this.brand = brand;
    }

Although the usefulness of this feature is definitely arguable, I do want to share this. :-)