I forgot the codez...

As always, I commit way too quickly to my local repository, and then automatically push it, only to find out that i've done it wrong... There are two commands to know: git reset --hard [commit id] Returns your local repository to the specified commit id (assuming you're using the current branch) git push [repository] +[commit id]:[branchname] Returns the remote repository to the commit id. When executing both, you both reset the remote, and local repository to the specified commit... as if the rest never happened (well, it's there, but you don't see it... that's a different story)

The Httpservletrequest has a lot of properties/parts which can be questioned. Which is which, you might ask? Some blog mentions them all: http://codyburleson.com/2013/09/18/getting-parts-of-a-url-from-the-httpservletrequest-object/

We all love annotations. Really, they're nice markers for your pointcuts, create the option to have cross cutting concerns easily (i.e. only log these marked fields, or mask these annotated fields when logging). However, we do need to be able to *get* to those annotations at runtime to inject those fancy tricks we have up our sleeve. In comes the beautiful google reflections library which allows us to scan the class files for annotations. Of course, we made those annotations available at runtime, right? If not, add @Retention(RetentionPolicy.RUNTIME) to the annotation ;) So, scanning at runtime done easy: Collection<URL> urls = ClasspathHelper.forPackage("nl.shopname.location.domain");   Reflections reflections =                 new Reflections(new ConfigurationBuilder().setUrls(urls).setScanners(new FieldAnnotationsScanner())); Set<Field> fieldsWithAnnotation = <reflections.getF...

I'm one of those guys who uses TabMixPlus for my Firefox, since I like the behaviour of Ctrl-Tab to be like Windows-Tab, i.e. jump to previously opened tab. You also want this in eclipse, right? So, modify the key bindings in Window->preferences->keys and modify the 'next editor' to Ctrl-Tab ... and 'previous editor to Ctrl-Shift-Tab. Voila! (it'll also show a small window in the order of which the tabs were opened... that's just gravy ;) )

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...