February « 2011 « Pragmatic Programmer Issues

Archive for February, 2011

JPA2 Metamodel – how to manage that.

Tuesday, February 22nd, 2011

JPA2 added new typesafe Criteria API. This allows us to build query in strongly-typed manner instead of string based. To provide such functionality JPA2 use Metamodel API described in JSR-317: Chapter 5.

When entity manager factory is bootstrapping for persistence unit, then persistence provider have to initialize metamodel classes so this classes have to be accessible. For application developers it is important to easy generate them.

We can automatically generate metamodel classes we use Annotation Processing API. The structure of metamodel classes are described in JSR-317: Chapter 6.2.1.1. Briefly for every managed class there will be similar class with name of metamodel class plus “_”, and for every property there will be SingularAttribute for non-collection and
Attribute for Collection|Set|List|Map attribute.

Thanks to that metamodel classes we can write a query, which is type safe and probably more important we can easy do refactorings. That’s in theory, because IDE have to have access to metamodel classes, so the question arise how to manage this classes. I was wonder about three option here:

Keep generated metamodel as normal code and commit into repository.
Use external tool to generate metamodel and include results as IDE sources.
Use IDE support, if exists.

First solution is portable, no IDE configuration, no problems between different IDE’s and so on. The disadvantage of this solution is that we have to remember about generating metamodel classes after we change our code and than commit metamodel into repository. Obviously we break the version control system rule, “don’t commit generated files“.

Second one assumes that you are using some kind of build tool (eg. maven). Then we can setup generation step into that tool (for maven it is maven-processor-plugin) and we setup our IDE to point to that sources. The bad thing about that is that we have to run the tool, otherwise we have not actual metamodel.

Third one is use your IDE for that. Sadly configuration isn’t automatic and every IDE has it’s own way to do this. JPA 2.0 Typesafe Criteria API and Annotation Processing Howto article describes how to do this in IntelliJ IDEA.

Both second and third solution has one additional flaw. You have to specify which annotation generator you want to use. That ties you to JPA provider implementation.

Here you find annotation processor names:

EclipseLink: org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor
Hibernate: org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor
OpenJPA: org.apache.openjpa.persistence.meta.AnnotationProcessor6

We can find processor parameters and switches in javadocs, in EclipseLink case, processor is in internal package, that makes finding parameters and switches a little bit harder, but we can check source code, or use Google.

I try to use third one and second one as fallback for people which use different IDE than IntelliJ, but I’m not happy with that solution.

How do you process JPA2 metamodel classes?

Tags: java
Posted in java | 2 Comments »

Pedro Newsletter 22.02.2011

Tuesday, February 22nd, 2011

Python 3.2 was released. Read “What’s new” for more details.
Java Agent for Memory Management: Unfortunately project is managed by ant.
Interview with Secure Programming Static Analysis Brian Chess by InfoQ. Brian tells us when to use penetration testing and why static analysis is also important for overall application security.
20 Google Docs Tips.

Posted in news | No Comments »

Spring Template Objects Testing

Monday, February 21st, 2011

My friend asked me, how we should test this piece of code

public void fire(final NotificationMessage message) {
  jmsTemplate.send(new MessageCreator() {
    @Override
    public Message createMessage(Session session) throws JMSException {
      return session.createObjectMessage(message);
    }
  });
}

Mock, stubs, arguments matchers are not successful here. Of course we can mock jmsTemplate, verify if send method was executed, but this way we only test if springframework works properly. Should we leave this to integration test?

Of course not, and our business part is: session.createObjectMessage(message). We have to change our code. First at all we provide second method.

public void fire(final NotificationMessage message) {
  this.fire(message, getMessageCreator(message));
}
public|protected| void fire(final NotificationMessage message, MessageCreator mc) {
  jmsTemplate.send(mc);
}

This two methods are easily testable by using mocks and verifying object interactions. We can decide about method modifier:

public – if we want second function to be available in our API.
protected – for future subclass usage.
package public – for use in package.
or even private

Finally we have decide about getMessageCreator(message).

Provide Factory Method for it: MessageCrator getMessageCreator(NotificationMessage message);

MessageCreator getMessageCreator(final NotificationMessage message) {
  return new MessageCreator() {
    @Override
    public Message createMessage(Session session) throws JMSException {
      return session.createObjectMessage(message);
    }
  };
}

Create Class which implements MessageCreator interface

public class NotificationMessageCreator implements MessageCreator {
    private final NotificationMessage message;

    public NotificationMessageCreator(NotificationMessage message) {
        this.message = message;
    }
    @Override
    public Message createMessage(Session session) throws JMSException {
        return session.createObjectMessage(message);
    }
}

I think both approaches are ok, so choose better one for you.

Of course you may argue that you don’t need unit test, you will have integration test for that part of the code. Unfortunately integration tests are slow and from time to time they fail, so for simple check I prefer unit test.

Summary

We use a lot of Spring Template Object helpers, and most of the time we are tempted to create anonymous class in place. This way we make our code hard to unit test. Consider this approach to make your code easier to test and maintain. What do you think about that?

Tags: java, spring, testing
Posted in java, spring, springframework, testing | 2 Comments »