How to JUnit-test Envers

Recently, me and some fellow students of mine had to do a homework assignment with Spring and Hibernate. One of the requirements was to include versioning for some of the entities.
At first we thought about programming something on our own by using AOP and an interface. After suggesting this to our professor he told us, that there might be already a framework for versioning that works with Hibernate.
So I found Envers.
Using Envers isn't very difficult. If you want to know more about Envers, you'll have to take a look at its documentation.
My problem was how to write JUnit-Tests for the methods in my DAOs that use the AuditReader class.

Before I start explaining my problem and my solution I just want to tell you, that I'm no Spring developer and it was my first project with Spring (my teammates had no experience with Spring, too).

When persisting some objects in the tests Envers never wrote any data into its revision tables. I soon found out that the @Transactional annotation at my test-class put every method in one transaction (Spring people will know ;) ). At the end of one test-method the commit was performed and Envers didn't react.
So @Transactional had to vanish and the search began.

So when I tried to find a solution I found this article on Dzone but calling commit() on my session or using the TransactionManager lead to some exceptions.
This thread on stackoverflow finally was the solution. Unfortunately the second answer doesn't have any rating, so I ignored it and I had to visit that thread three times to recognize it. (please rate it up if you're registered on stackoverflow)

The superclass for all my Envers tests looks like this: ApplicationContextAwareTest
and in every test it use this method with the TransactionTemplate:

public <T> T makePersistentInTransaction(final T toPersist,

  final GenericDAO<T, Long> dao) {

 return transactionTemplate.execute(new TransactionCallback<T>() {



  @Override

  public T doInTransaction(TransactionStatus status) {

   return dao.makePersistent(toPersist);

  }

 });

};

After every call there is a commit and Envers starts working. And after persisting some objects I can tests my methods, which take care of versioning.
Finally everything could be tested and I was happy :D 

Feel free to browse the GitHub project. It contains the whole homework. And please don't wonder that nearly everything is in German ;)

Read More

Sorry for the delay

I know I promised you some information about Ivy and I am really, really late.
But studies and watching the European Soccer Championship consumed lots of time.
And right now, I am back at learning some Python and I gotta admit (again) that

a = []

looks much more elegant than

List<Object> a = new ArrayList<Object>();

Of course the compact list syntax is a feature and Groovy e.g. has the same ability.

And now to the promised Ivy part (it won't be long, because I don't want to duplicate the tutorial, which can be found here):
For me, Ivy is quite straightforward with its ivy.xml and the dependencies in there and the ivy.xml looks like the dependencies in a Maven POM.
Also adding <ivy:retrieve/> to your build.xml shouldn't be too complicated ;)
Having different repositories like Maven is also possible.
And, what I recently found out is, that Gradle and SBT work with Ivy, too.

So, give it a try.

Read More

Getting started with Apache Ivy

Well, no big knowlegde sharing today, I just wanna let you guys know what I am up to.
2 days ago I discovered, that there is something called Apache Ivy. I was quite surprised that I never recognised it before.
Ivy is a dependency manager and it seems to me like a good way to keep your Ant build.xmls and to have the (very comfortable) dependency resolution from Maven.

So, my task for the weekend is to find more out about Ivy. I hope I'll be able to write a little bit more on Sunday.

Read More

How I can use my time...

I just found a good way how I could use my time a little bit better:
Every day I ride my bicycle 20 minutes to my workplace and 20 minutes back.
During that time I didn't do more than cycling (and taking a look at the landscape ;) ).

Thanks to the book 97 Things Every Programmer Should Know I realised, that I could use my time better:
I started to listen to podcasts on my way.
I am quite sure that I am not the first person who found out that that's possible, nevertheless it just came to my mind a short while ago.

Now I listen to some interesting software engineering podcasts (at the moment Software Engineering Radio and the German heise developer). If you can recommend some more podcasts feel free to leave a comment.

So, try to think about your daily routine and maybe you'll discover (like I did) some time interval you could use better.

Read More

A lot of work with CDI

I didn't write a lot of posts these days, that's because CDI is taking my full attention.
CDI is quite a nice invention for Java EE but despite my first thought, it's not just about injection.
All those

• Interceptors
• Decorators
• Portable Extensions
• ...

are nice things. It's just that you have to learn about them. But I have to thank Gavin King and the JSR-299 Expert Group for writing a very good and understandable specification. If you want to learn more about CDI and you're tired of all those tutorials on the internet, try to take a look at the specification. You can find it here. They put some really good examples into the first chapters, too.
So, have with injection ;)

Read More

@Nonbinding

I experiment recently a lot with CDI and one point I stumbled upon were the return values of my annotation functions.
Consider an annotation like this:

@Qualifier

@Retention(...)

@Target(...)

public @interface MyInterface{

 String value();

}

I tried to combine this annotation with a producer method and to use the value in the method (by asking the InjectionPoint for its value). Every time my Eclipse tried to deploy the .war it showed me an error.
After a while I found out that the only way to evade this, is to use the annotation @Nonbindung.
The altered annotation looks like this:

@Qualifier

@Retention(...)

@Target(...)

public @interface MyInterface{

 @Nonbinding

 String value();

}

Maybe I didn't read the spec good enough, but it took me a while to find that out.
So I hope you guys won't have the same problem like me ;)

Read More

new vs. valueOf() in Java primitive wrappers

Did you ever take a close look at the Javadoc which is written at, for example, Integer.valueOf()?

No? Ok, I'll tell you ;)

It says you should prefer using the valueOf() method instead of using Integer's constructor. You'll find the same annotation at all the other wrapper classes for the primitive types in Java. (in Double, the Javadoc says the same, but double doesn't have a cache, weird...)

The reason is that Java will cache some values, so the VM won't create a lot of new objects.
I cannot imagine a certain case, when I explicitly need a new Integer or something similar (maybe in a JUnit-Test). A friend of mine mentioned when it's the key of a WeakHashMap.

So the next time you want to type new Integer(...), consider using Integer.valueOf(...) ;)

Read More