NetBeans RCP & JPA (Part 2)

In my previous post at DZone, I talked about how to make JPA aware of the existence of multiple persistence.xml files, possibly one for each NetBeans RCP module, and able to merge them together. There were some rough corners, and now I've fixed one - furthermore I've also addressed another integration problem with JPA.

Please be aware that most of the code I'm showing you is now factored out of blueMarine and is available at https://openbluesky.dev.java.net/svn/openbluesky/trunk/src/Libraries/JPA - the revision used for this article is 225.

As you know, JPA is just an API specification, which is implemented by different vendors, e.g. Hibernate, TopLink (TopLink Essentials, part of Glassfish, is the reference implementation) and OpenJPA. This means that you have two groups of JAR files: the one including only the public API classes (that for simplicity I'll name jpa.jar) and the one including all the implementation stuff, plus the required libraries (again, for simplicity, I'll name it vendor.jar, even though usually there are multiple files).

For maximum flexibility and portability you usually do the following things:

1. compile your application against jpa.jar, ignoring vendor.jar
2. put in the classpath jpa.jar and the vendor.jar from your favourite implementor

In this way you can just replace the vendor.jar in different deployment contests, and have the thing working all the same.

The problem

When I tried to to that for the first time with blueMarine, a few months ago, I wasn't able to work it out. The basic idea, of course, is to create two NetBeans RCP Library Wrapper Modules, the former named JPA containing jpa.jar and the latter named Hibernate and containing vendor.jar; of course, the Hibernate Wrapper depends on the JPA Wrapper. You could create as well a module named TopLink which again depends on JPA, and so on. Your modules which use the classes in javax.persistence.* would just declare a dependency on JPA only, and you can then add to your RCP application either the Hibernate module or the TopLink module as you wish.

This doesn't work because of the dynamic discovery mechanism implemented in jpa.jar. Basically, the class Persistence searches for the JPA implementation by asking to the classloader to retrieve all the META-INF/services/javax.persistence.spi.PersistenceProvider files which contain the name of che implementation class. While this works in standard Java, under NetBeans RCP it won't discover Hibernate, since... the JPA Wrapper doesn't depend on the Hibernate Wrapper! While introducing this dependency would be formally wrong, you can't either accept it as a hack, otherwise you would get a circular dependency (remember that the Hibernate Wrapper is already depending on the JPA Wrapper) that is not allowed by the NetBeans RCP platform.

So far, I had to put both jpa.jar and vendor.jar in the Hibernate module, and have all of my code depending on it.

The solution

One way to fix the problem is to make a small patch to the JPA sources, more precisely in the javax.persistence.Persistence class and replace the discovery mechanism with the NetBeans RCP one, that is by using Lookup:

package javax.persistence;

import java.util.Map;
import java.util.logging.Logger;
import javax.persistence.spi.PersistenceProvider;
import org.openide.util.Lookup;
import it.tidalwave.netbeans.jpa.PersistenceProviderDecorator;

public class Persistence
  {
    private static final String CLASS = Persistence.class.getName();
    private static final Logger logger = Logger.getLogger(CLASS);

    private static PersistenceProvider persistenceProvider;

    public Persistence()
      {
      }

    public static EntityManagerFactory createEntityManagerFactory (final String persistenceUnitName)
      {
        return createEntityManagerFactory(persistenceUnitName, null);
      }

    public synchronized static EntityManagerFactory createEntityManagerFactory (final String persistenceUnitName,
                                                                                final Map properties)
      {
        if (persistenceProvider == null)
          {
            final PersistenceProvider delegate = Lookup.getDefault().lookup(PersistenceProvider.class);

            if (delegate == null)
              {
                throw new PersistenceException("No PersistenceProvider delegate found");
              }

            logger.info("PersistenceProvider delegate: " + delegate.getClass());
            persistenceProvider = new PersistenceProviderDecorator(delegate);
          }

        final EntityManagerFactory emf = persistenceProvider.createEntityManagerFactory(persistenceUnitName, properties);

        if (emf == null)
          {
            throw new PersistenceException("No Persistence provider for EntityManager named " + persistenceUnitName);
          }

        return emf;
      }
  }

Now, the class will be able to discover JPA implementations in any module, because the default Lookup has global visibility. To create this new JPA module, I've just extracted the javax.persistence.* sources from the Glassfish distribution and patched them - it's ok to do that, since they are release through the GPL v2 + Classpath Exception, so you're only forced to redistribute the thing, which I'm doing.

Indeed, I think there could be a way to implement this thing _without_ patching the existing files: you could just embed in the JPA Wrapper a proxy provider, which in turn would call Lookup. I'll try it before writing Parth Three of this series.

Having the standard Lookup plugged in will bring us additional flexibility, as you'll discover by reading the last paragraph of this post.