I forgot the codez...

To run a traditional java program we have to start a main class, preferably in a JAR. However, these jars usually have dependencies, which need to be on the classpath. This leads us to two options: 1) we create a 'fat' jar, in which all are included (see one-jar, which I talked about here ) 2) when we are allowed to use maven, we can let maven create the classpath for us. In this post, I'll discuss option 2. With the maven exec:java plugin (documented here ), we can execute a main class from a specific jar. Maven then builds the classpath! For an example, we assume we have a main class in my.personal.projects.MainClass, which is hosted in the my.personal.projects.coolapp-1.0.jar, which is in the repository. It might have any number of dependencies. A sample pom.xml looks like the following:      <dependency>         <groupId>my.personal.projects</groupId>         <artifactId>coolapp<...

Sometimes, you do not have the option to deploy to an applicationserver, and it is necessary to release a single stand-alone jar. For this, we can use the excellent one-jar code, or, the maven one-jar plugin. A simple link to the documentation should suffice. It is exactly what you want as it supports it's own classpath, ensuring that multiple files can exist with the same name (of course, it'll warn you about that, but). It's much better then the normal maven assembly plugin, as it gives all sorts of problems. You can then use the normal java -jar myOneJar.jar to start your program. Of course, if you're allowed to use maven, you can let maven set up the classpath for you... But that will be in a different post.

In spring you can use the @Transactional annotation to marcate public methods as transactions. Any exception thrown in such an exception causes a rollback... Any exception? No, spring only does so on runtime exceptions. Checked exceptions are allowed and do not result in a rollback. And even then, you can allow some transactions to rollback, or not, with the proper properties for the transactions. For examle, @Transactional(rollbackFor="MyCheckedException.class") will rollback for a specific checked exception, and similarly, you can use @Transactional(noRollbackFor="MyUncheckedException.class") for unchecked exceptions. Of course, you might want to make it a little simpler on yourself. This article on stackoverflow shows us a different way: we can use our own transaction handler by overriding spring's. Let's have a sample interface which defines whether an exception should perform a rollback: interface ConfigurableRollback shouldRollbackOnE...

Oracle can run in a cluster, also called Oracle RAC (real application cluster - what's in a name that they need to call it a REAL cluster...). This means that at any time a machine in the cluster can be removed from the cluster, and hence all connections to it dropped. This, of course, does not give high availability... which is one of the reasons we actually have a cluster in the first place. Oracle, in all its wisdom, considered this an let the client-side oracle driver detect this and throw an exception, which then needs to be caught and handled, and by handling it the action can be redone. Of course, this means having a transaction being rolled back (because really, we're talking oracle and that means enterprisey), and we would want to redo that transaction. To make this easy, the spring-data jdbc extensions has a rac failover interceptor which does this for you. It wires itself to all transactional annotated methods, and retries a number of times. Of course, we ca...

Last week I was trying to encode some encrypted data as a cookie. After encrypting the data, I was left with a byte[] array. So all that was left was to create a string, and then fix all the strange characters... preferably by base64 encoding it, for example. That worked fine, until I wanted to decode the string. All of a sudden the byte[] array was no longer the same... well, sometimes, it wasn't. byte[] data = new byte[20]; new Random().nextBytes[data]; // fill with some random data. String myString = new String(data); byte[] fromString = myString.getBytes(); for(int i = 0; i < data.length; i++) assert(data[i] == fromString[i]) The code above will fail... from time to time. This is rather strange, and not directly obvious from the javadoc. First I considered if it was an encoding problem. This only compounded the issue, as new String(data, "UTF-16" ).getBytes().length is twice the size of the original data. That was leading nowhere. After lo...