I’m currently under the process of moving all my workplace repositories from SVN to Git (configured to work with Gerrit). As a side not, I already found it to be a great tool for code review, line-precise commenting of the artifacts and for reviewing new employees code before pushing the changes to the repository.

But, back to my point. Recently I’ve stumbled upon a problem with commiting an empty directory in Git. If the directory consists of some files and you stage those files, the directory will be commited automatically. However, if the directory is empty, you cannot commit it.

It’s very reasonable way of thinking, but it also creates a few problems e.g. with Eclipse which requires you to use some Maven defined directories (src/test, src/java, etc.). More precisely, if you don’t have e.g. src/test/resources directory, it will throw an ugly project-wide error at your face.

The solution, can be found on StackOverflow, so basically all you need to do is provide a .gitignore file which forbids content other than the .gitignore file itself. However, in my case I ended up with putting a README file which describes why it’s there and that it should be removed as first real resource will be uploaded.
I found it more informative for other team members than an empty .gitignore file.

Sometimes you might be struggling with such error shown, e.g. in Eclipse:

The method …… must override a superclass method.

If this error is shown in the line when you have your interface method implementation with @Override annotation, it most probably means that you’re using JDK 5 instead of JDK 6.

In Java 5, the @Override annotation might be applied only to the methods overriding superclass ones. Since Java 6 you can use the @Override annotation also with the methods that implements the interface ones.

Therefore, if you see such error, either change the JDK to JDK 6 (i.e. check your Eclipse workspace or project preferences) or, if you need to be compatible with JDK 5, remove the @Override annotations from interface implementation methods.

Simple thing but it might make you swear ;-)

I’ve had some problem with starting the GlassFish database. It occurs that in GlassFish 3.1 it started together with the Application Server (when you started the domain), but this doesn’t work for me since 3.1.1.

So, if you see something like:

Error connecting to server localhost on port 1527 with message Connection refused: connect.

you can try to start the GlassFish Java DB by yourself. To do this, just invoke:

asadmin start-database

while you’re in GLASSFISH_HOME/bin directory.

By default, Maven’s test plugin Surefire doesn’t scan files for @Test annotations, but rather takes only the files which class names ends with “Test” or “TestCase”.

I use both: unit tests and integration tests. I execute the latter using Arquillian framework, so it looks just like pure JUnit test. However, I prefer to name them with the “IT” suffix which means that they’re no longer recognized by Surefire plugin as test files.
If you want Maven to execute such tests, you need to give him a hint (using appropriate configuration element) to scan also for the *IT classes:

<configuration>
    <includes>
        <include>%regex[.*[Test|IT].class]</include>
    </includes>
</configuration>

Just remember that the regex works only on *.class files. It also overrides the default rules (which means that you need to add the *Test and/or the *TestCase suffix to scan for default test classes.)

Recently, I’ve bumped into few posts on StackOverflow where people tend to compare container managed EntityManager instances (so the one injected by the container) by invoking EntityManager#toString() method. I’ve felt that it’s fundamentally wrong to compare EntityManager instances without knowing how they’re managed by the JPA provider or the Server Application. And what if this behaviour differs between Application Server vendors?

The JPA provider provides an implementation of EntityManager – that’s obvious. More interesting is that the Application Server is scanning all @PersistenceContext fields and wrapping these EntityManagers into its own class – a proxy – which delegates requests to the JPA provider’s EntityManager. Therefore, if you’re comparing results of toString() method of such EntityManagers, you can’t say about PersistenceContexts equality but rather about Server Application EntityManager equality.
Needless to say, an Application Server could use one proxy as an access point to different EntityManagers. Without knowing the internals, you’re not able to say how it will work and decide if your results are meaningful.

Continue reading

You probably know that if you use BMT (Bean Managed Transactions) you can get information about current transaction status by using UserTransaction interface (which implementation can be fetched either by JNDI or using dependency injection) and executing it’s getStatus() method.

If you use CMT (Container Managed Transactions) you cannot use UserTransaction interface. Instead, you can manage your transaction through SessionContext interface. This interface gives you two places that hooks to the current transaction: setRollbackOnly(-) and getRollbackOnly().
But what if you would like to check the current transaction’s status?

Well, the first answer would be: think twice if you really need to do this.

The transaction is container managed, so get/setRollbackOnly(-) should be probably the most important methods for you.

However, if you still need to get some more detailed information about your CMT you can use the TransactionSynchronizationRegistry interface which (just like UserTransaction) can be fetched using JNDI or @Resource annotation:

@Resource
TransactionSynchronizationRegistry txReg;

txReg.getTransactionStatus();

Here you can find what the integer status returned by this method invocation means.

Just a note to myself – always check what classes are you importing in IDE, because if you see @Singleton in your class, it doesn’t mean it will work as a EJB Singleton. In my case it wasn’t referencing to javax.ejb.Singleton as I assumed, but com.sun.jersey.spi.resource.Singleton

Wasted 2 hours of looking for the answer or issue in a glassfish-3.1 JIRA.

Did I mention I should always check the exact package of the imported class…?

If you want to add your classes (or any other resources) to your ShrinkWrap archive to a non-root location, you can use the following:

@Deployment
public static JavaArchive deploy() {

   // This is the classes and resources archive
   JavaArchive ar;
   ar = ShrinkWrap.create(JavaArchive.class, "resources.jar")
                  .addPackage(TestClass.class.getPackage());

   /*
    * The 'ar' archive will be added to the 'yourDir', so you'll
    * end with test.jar#/yourDir/TestClassPackage/TestClass.class
    */
   JavaArchive endArch;
   endArch = ShrinkWrap.create(JavaArchive.class, "test.jar")
                       .merge(ar, "yourDir");

   endArch.merge(ar, "yourDir");

   return endArch;
}