EclipseLink/Development/OSGi

From Eclipsepedia

Jump to: navigation, search

This page is focussed on capturing how EclipseLink will be developed and used for an OSGi (Equinox) environment and is motivated by Bug 210979.

The goal of this effort is to produce OSGi bundles for use in other Eclipse projects and RCP applications. While the focus is on OSGi it is understood that Equinox extensions may be required.

Contents

Requirements

  1. Provide EclipseLink bundles that are easy to use within other Eclipse projects and RCP applications
  2. Provide EclipseLink JAR files that enabled Java SE and EE usage
  3. Ensure that the bundles offer flexibility in their independent usage. The usage of EclipseLink JPA should not force the usage of EclipseLink's JAXB

Rationale

  1. Enable other Eclipse projects and those building Eclipse RCP applications to more easily consume EclipseLink (project MayInstall, EMF Teneo)
  2. Address our stated project goal to define a blue-print for persistence services usage in OSGi
  3. As a member project of the proposed top level runtime project centered around Equinox we must be usable in an Equinox environment

Current Status

As of 1.0M3 EclipseLink does not make OSGi/Equinox bundles available. This page is tracking the requirements, proposals, and discussion as to how EclipseLink can most effectively be bundled.

Here is the [EclipseLink/Development/EclipseLinkPDEConversionPlan | Detailed PDE Conversion Plan]

Proposal

To explore the packaging of EclipseLink as OSGi bundles, a branch should be created in the SVN repository. This branch will provide a safe "sandbox" in which to experiment with different packaging and integration strategies. It will also provide a way for EclipseLink developers and community members to access, try, and provide feedback on the approach.

The approach to supporting OSGi being proposed includes:

  • Conversion of all EclipseLink projects to PDE projects to support development, debugging, and testing in an OSGi environment.
    • This would require all developers of EclipseLink to be aware of how to develop using PDE rather than directly in JDT (e.g., classpath's defined through required bundles instead of require projects).
  • A bundle containing the JPA specification classes contained in javax.persistence.
    • Modification of javax.persistence.Persistence to introduce a pluggable mechanism for JPA Provider resolution. The spec provided implementation relies on classpath scanning which doesn't work in an OSGi container. This would support the use of JPA providers other than EclipseLink in an OSGi environment.
    • Applications requiring JPA would require the javax.persistence bundle, not EclipseLink (unless using EclipseLink extensions). EclipseLink JPA would be discovered through the OSGi Service Registry.
  • A bundle containing the JAXB specification classes contained in javax.xml.bind.
    • It's expected that a modification to the spec classes similar to those proposed for JPA would be necessary to deal with classloader issues.
  • A service based approach to extending EclipseLink with database and server platforms.
    • To avoid EclipseLink foundation having compile time dependencies on specific database or server platform APIs, such classes are contained in separate bundles. For example, in SVN, Oracle database platform classes are housed in the eclipselink.extension.oracle project. In OSGi, classloader restrictions mean that EclipseLink foundation classes cannot directly load database platform classes identified in persistence.xml properties. Through a service based approach, EclipseLink will obtain the identified platform classes from a service.
  • A service based approach to obtaining JDBC Drivers.
    • The rationale is similar to that for database and server platforms--classloader limitations do not make it possible for EclipseLink to see classes unless it explicitly pre-reqs the bundle containing a driver. This is not extensible. The OSGi solution to this problem (see OSGi RFC 122) is for the drivers to be registered as services and to look them up when needed.

Proposed Bundles

  • javax.xml.bind
    • Spec classes and interfaces augmented with support for discovering JAXB provider services.
  • org.eclipse.persistence.foundation
    • Native object-relational persistence using ElcipseLink-ORM.XML or API
    • Native Object-XML API using native XML mapping file or API configuration
  • org.eclipse.persistence.foundation.lib
    • Contains various libraries required by EclipseLink. Likely this bundle will eventually be unnecessary as the required Java libraries are either bundled separately or obtained from Orbit. The focus of this work is on packaging EclipseLink so the packaging of all the required libraries will not be addressed by this investigation.
  • org.eclipse.persistence.jpa
    • JPA 1.0 functionality
    • Extended JPA support using EclipseLink's annotations, PU properties, and query hints
    • Support for partial and complete EclipseLink-ORM.XML extensions of JPA
  • org.eclipse.persistence.moxy
    • JAXB 2.0 using annotations
    • JAXB 2.0 using native XML mapping file
  • org.eclipse.persistence.sdo
    • SDO 2.1 support
  • org.eclipse.persistence.eis
    • Native Object-EIS/JCA using native XML mapping file or API configuration

Proposed Persistence Service and Extensions

This is an example of an Eclipse (RCP) application for a library. The first part of the example is from the point of view of the application developer. The second part is what goes on behind the scenes to make it all work.

Part 1: The Developer

The domain consists of one class: Book which is defined in the plugin org.acme.library.

package org.acme.library.entity;
 
@Entity
@Inheritance(strategy=InheritanceType.TABLE_PER_CLASS)
public class Book
{
  @Id
  @Generated
  private long id;
  private String title;
  private String abstract;
  ...
}

The entity is declared as an extension in the plugin.xml (look Ma', no persistence.xml)

<plugin>
   <extension point="org.eclipse.persistence.jpa.persistenceContext">
      <context name="org.acme.library">
         <entity class="org.acme.library.entity.Book"/>
      </context>
   </extension>
</plugin>

Here is how a Book would be accessed using the proposed persistence service

IPersistenceService persistenceService = Activator().getDefault().getPersistenceService();
EntityManager em = persistenceService.createEntityManager("org.acme.library");
Book book = em.find(Book.class, 4368);
em.close();

Now, consider the library expanding and adding audio books. The class AudioBook is defined in the plugin org.acme.library.audio.

package org.acme.library.entity;
 
import org.acme.library.Book;
 
@Entity
public class AudioBook entends Book
{
  private boolean abridged;
  private String storyteller;
  ...
}

The entity is declared as an extension in the plugin.xml

<plugin>
   <extension point="org.eclipse.persistence.jpa.persistenceContext">
      <context name="org.acme.library">
         <entity class="org.acme.library.audio.entity.AudioBook"/>
      </context>
   </extension>
</plugin>

At runtime, the declared entities from the two plugins are combined into a single persistence context.

IPersistenceService persistenceService = Activator().getDefault().getPersistenceService();
EntityManager em = persistenceService.createEntityManager("org.acme.library");
Book book = em.find(Book.class, 4368);
AudioBook audioBook = em.find(AudioBook.class, 148905);
em.close();

Part 2: The Black Magic

When the persistence service starts, it loads various extensions. The first is loading of the IPersistenceConfigurationFactory. The factory takes the database connection information and creates a mapping of parameters specific to the JPA provider. My current implementation only allows for a single provider to be active for the application. To support multiple providers in the same application, the factories could be associated with some sort of provider id.

public interface IPersistenceConfigurationFactory
{
  Map<String, String> createConfiguration(DatabaseConnectionInfo connectionInfo);
}

Here is the code for the Hibernate provider. This factory only support MySQL and DB2. Some additional work is needed to make database support generic.

public class PersistenceConfigurationFactory implements IPersistenceConfigurationFactory
{
  public Map<String, String> createConfiguration(DatabaseConnectionInfo connectionInfo)
  {
    StringBuilder uri = new StringBuilder();
    uri.append("jdbc:");
    uri.append(connectionInfo.getType());
    uri.append("://");
    uri.append(connectionInfo.getServer());
 
    if(connectionInfo.getPort() > 0)
    {
      uri.append(':');
      uri.append(connectionInfo.getPort());
    }
 
   uri.append('/');
 
    if(connectionInfo.getDatabase() != null)
      uri.append(connectionInfo.getDatabase());
 
    final HashMap<String, String> config = new HashMap<String, String>();
    config.put("hibernate.dialect", getDialect(connectionInfo.getType()));
    config.put("hibernate.connection.driver_class", getDriver(connectionInfo.getType()));
    config.put("hibernate.connection.url", uri.toString());
    config.put("hibernate.connection.username", connectionInfo.getUser());
    config.put("hibernate.connection.password", connectionInfo.getPassword());
 
    return config;
  }
 
  private String getDialect(String type)
  {
    if (type.equals("mysql"))
      return "org.hibernate.dialect.MySQLDialect";
    else
      return "org.hibernate.dialect.DB2Dialect";
  }
 
  private String getDriver(String type)
  {
    // TODO better driver support
    if (type.equals("mysql"))
      return "com.mysql.jdbc.Driver";
    else
      return "com.ibm.db2.jcc.DB2Driver";
  }
}

Here is the declaration of the extension:

  <extension point="com.ibm.hdwb.core.persistence.ejb.configurationFactory">
    <factory class="com.ibm.hdwb.core.internal.persistence.ejb.hibernate.PersistenceConfigurationFactory">
    </factory>
  </extension>

The second extension point loaded is the declaration of the entities. The class names of the entities are stored in a map keyed on the persistence context.

private final HashMap<String, HashSet<String>> entities;

There is a third extension point that maps the persistence context to a database URI. These entries are stored in a map keyed on the persistence context.

private final HashMap<String, URI> configuration;

When a client requests an EntityManager, the context name is used to locate the EntityManagerFactory from the cache of factories. If the factory is found in the cache, it is used to create and return the EntityManger. If the factory does not yet exist, The persistence context name is used to locate the database URI from the configuration. From the database URI, the DatabaseConnectionInfo is obtained via an extension point. Once the DatabaseConnectionInfo is available, the IPersistenceConfigurationFactory is used to create the JPA provider specific configuration info for the persistence context. From the persistence context configuration, a PersistenceFactory is created that is a proxy for the EntityManagerFactory. The PersistenceFactory is responsible for working around context classloader issues (present in Hibernate) and creating the persistence.xml.

	public EntityManager createEntityManager(String instance, IProgressMonitor monitor, Map<String, String> config) throws PersistenceServiceException
	{
		monitor.beginTask("Connect to database", 4);
 
		PersistenceFactory factory = factories.get(instance);
		monitor.worked(1);
 
		if (factory == null)
		{
			if (entities.containsKey(instance))
			{
				final Map<String, String> conf = createConfiguration(instance);
 
				if(conf == null)
				{
					final Status status = new Status(IStatus.ERROR, Activator.PLUGIN_ID, PersistenceService.STATUS_ERROR, "The datasource for the instance '" + instance + "' could not be found", null);
					Activator.getDefault().getLog().log(status);
					throw new PersistenceServiceException(status);					
				}
 
				conf.putAll(config);
				factory = new PersistenceFactory(instance, entities.get(instance), conf);
				factories.put(instance, factory);
			}
			else
			{
				final Status status = new Status(IStatus.ERROR, Activator.PLUGIN_ID, PersistenceService.STATUS_ERROR, "The persistence context instance '" + instance + "' could not be found", null);
				Activator.getDefault().getLog().log(status);
				throw new PersistenceServiceException(status);
			}
		}
 
		monitor.worked(1);
		factory.connectToDatabase();
		monitor.worked(1);
 
		return factory.createEntityManager();
	}
 
	private Map<String, String> createConfiguration(String persistenceContext)
	{
		final URI datasource = configuration.get(persistenceContext);
 
		if (datasource == null)
			return null;
 
		final DatabaseConnectionInfo connectionInfo = Activator.getDefault().getConnectionService().getConnectionInfo(datasource);
		return configurationFactory.createConfiguration(connectionInfo);
	}
public class PersistenceFactory
{
	public PersistenceFactory(String context, Set<String> entities, Map<String, String> properties)
	{
		active = false;
		persistenceContext = context;
		contextProperties = properties;
		this.entities = entities;
	}
 
	public synchronized void connectToDatabase() throws PersistenceServiceException
	{
		if (factory != null)
			return;
 
		try
		{
			final ClassLoader oldLoader = Thread.currentThread().getContextClassLoader();
			final ClassLoader parentLoader = PersistenceActivator.class.getClassLoader();
			final PersistenceClassLoader newLoader = new PersistenceClassLoader(parentLoader, getPersistenceXML());
			Thread.currentThread().setContextClassLoader(newLoader);
			factory = Persistence.createEntityManagerFactory(persistenceContext, contextProperties);
			Thread.currentThread().setContextClassLoader(oldLoader);
			active = true;
		}
		catch (final Exception e)
		{
			final Status status = new Status(IStatus.ERROR, Activator.PLUGIN_ID, PersistenceService.STATUS_ERROR, "Failed to construct EntityManagerFactory for persistence context: '" + persistenceContext
					+ "'", e);
			Activator.getDefault().getLog().log(status);
			throw new PersistenceServiceException(status);
		}
	}
 
	public EntityManager createEntityManager() throws PersistenceServiceException
	{
		if (factory == null)
		{
			final Status status = new Status(IStatus.ERROR, Activator.PLUGIN_ID, PersistenceService.STATUS_ERROR, "Attempted to access the persistence context: '" + persistenceContext
					+ "' when it is off-line", null);
			Activator.getDefault().getLog().log(status);
			throw new PersistenceServiceException(status);
		}
 
		return factory.createEntityManager();
	}
 
	public synchronized void disconnectFromDatabase()
	{
		if (factory == null)
			return;
 
		factory.close();
		factory = null;
	}
 
	public String getPersistenceContext()
	{
		return persistenceContext;
	}
 
	public byte[] getPersistenceXML()
	{
		final StringBuilder xml = new StringBuilder();
		xml.append("<persistence>");
		xml.append(System.getProperty("line.separator"));
 
		xml.append("<persistence-unit name=\"");
		xml.append(persistenceContext);
		xml.append("\" transaction-type=\"RESOURCE_LOCAL\">");
		xml.append(System.getProperty("line.separator"));
 
		for (final String entity : entities)
		{
			xml.append("<class>");
			xml.append(entity);
			xml.append("</class>");
			xml.append(System.getProperty("line.separator"));
		}
 
		xml.append("</persistence-unit>");
 
		xml.append(System.getProperty("line.separator"));
		xml.append("</persistence>");
 
		return xml.toString().getBytes();
	}
 
	public boolean isActive()
	{
		return active;
	}
 
	Map<String, String> contextProperties;
	Set<String> entities;
	private boolean active;
	private final String persistenceContext;
	private EntityManagerFactory factory;
}

The loading of the persistence.xml is handled via a specialized ClassLoader, URLStreamHandler, and URLConnection:

public class PersistenceClassLoader extends ClassLoader
{
	PersistenceClassLoader(ClassLoader delegate, byte[] xmlData)
	{
		super(delegate);
 
		urls = new Vector<URL>();
 
		try
		{
			urls.add(new URL("bundleresource", Long.toString(Activator.getDefault().getBundle().getBundleId()), -1, "/META-INF/persistence.xml", new Handler(xmlData)));
		}
		catch (final MalformedURLException e)
		{
			e.printStackTrace();
		}
	}
 
	@Override
	public Enumeration<URL> getResources(String name) throws IOException
	{
		if (name.equals("META-INF/persistence.xml"))
			return urls.elements();
 
		return super.getResources(name);
	}
 
	Vector<URL> urls;
}
 
public class Handler extends URLStreamHandler
{
	public Handler(byte[] xmlData)
	{
		this.xmlData = xmlData;
	}
 
	@Override
	protected URLConnection openConnection(URL arg0) throws IOException
	{
		return new PersistenceURLConnection(arg0, xmlData);
	}
 
	byte[] xmlData;
}
 
public class PersistenceURLConnection extends URLConnection
{
	protected PersistenceURLConnection(URL arg0, byte[] xmlData)
	{
		super(arg0);
		this.xmlData = xmlData;
	}
 
	@Override
	public void connect() throws IOException
	{
	}
 
	@Override
	public InputStream getInputStream() throws IOException
	{
		final ByteArrayInputStream stream = new ByteArrayInputStream(xmlData);
		return stream;
	}
 
	private byte[] xmlData;
}

Dependent Bundles

JPA

  1. QUESTION: Is there any value in having JPA (persistence.jar) available as a separate bundle or is this just part of the API exposed from the org.eclipse.persistence.jpa bundle?
    • Having the javax.persistence classes available in a separate bundle would support the use of multiple persistence providers in a single application--having multiple copies of these classes can (as practical experience has shown me--Shaun) lead to nasty ClassCastExceptions.
    • Separating spec classes from the impl classes would support multiple spec versions independent of impl versions
    • Specification versions and implementations should probably be decoupled to be consistent with the expectations of OSGi users.

JAXB

  1. QUESTION: Should JAXB be a bundle or should it be advertised API from EclipseLink's MOXy bundle?
    • If we take the same approach to JAXB as is proposed for JPA then JAXB would be its own bundle and be extended to support resolving specific JAXB implementations through a service registry.
  2. QUESTION: If it is a separate bundle should the RI be included with the API to make it functionally useful on its own?

SDO

  1. NOTE: SDO's vendor implementation approach of customizing a class from the public API (Helper) will make bundling it interesting.
    • The SDO 2.1 spec classes contain a single static variable that holds a single SDO implementation class. This effectively makes it impossible to have two SDO implementations on your classpath. Also the way in which SDO bootstraps to find this sole implementation makes it impossible to have more than one. Given this is the case there is no motivation to make the SDO classes available in a separate bundle. They should be included in the EclipseLink SDO bundle.

Issues

  1. Current Proof-of-Concept packaging of EclipseLink into bundles has relied upon the Equinox Buddy Classloader extension. This approach is not portable to other OSGi containers and is therefore not a long term solution. In his blog, Peter Kriens, OSGi Director of Technology, describes his efforts to address classloader issues with Hibernate that are similar to those facing EclipseLink in an OSGi environment. Unfortunately he concludes that future versions of OSGi would require new features to solve the problem elegantly and portably.
    • Jan. 8, 2008 -- Further investigation has lead to an approach that does not require Equinox Buddy Classloaders. The solution is for EclipseLink to use the classloader of the bundle containing the JPA client code to perform class and resource loading. The challenge is in obtaining the classloader. One approach that has been prototyped is to use an Activator class in the the client application bundle to obtain the bundle classloader. This class can be identified through the Manifest.mf of a JPA client bundle. EclipseLink can listen for bundle events to identify JPA client bundles and obtain their classloader.
  2. Does packaging EclipseLink into OSGi bundles require the use of an OSGi service approach or is the JPA sufficient? Bryan Hunt, on the eclipselink-users mailing, list has described what a service based approach would look like.
    • Jan. 8, 2008 -- Prototyping has resulted in a fleshing out of the issue of using the Spec API vs. Services. The current thinking is that a hybrid of both is the way to go. The idea is that JPA client code would us the JPA spec API to obtain an EntityManagerFactory from javax.persistence.Persistence, but behind the scenes it would use a service approach to locate JPA providers. This approach would allow client code to ignore the underlying OSGi service mechanism and just use JPA as they would in an SE environment. It would also allow for the using of multiple JPA providers in the same OSGi container and even application.
  3. When dynamic weaving is enabled, EclipseLink will alter Entity classes as they are loaded to introduce a ValueHolder (proxy) for lazy OneToOne and ManyToOne relationships as well as fetch-groups and change tracking. How can byte code weaving work in an OSGi container? Support for AspectJ in OSGi and Equinox may provide some insight into this, and may even provide an API at some point.
  4. It is not uncommon for EclipseLink customers to actually modify the EclipseLink framework by either subclassing an EclipseLink class or adding another implementation of an EclipseLink interface. We need to work with the OSGi group to see what mechanism would best accomplish the case where some of the EclipseLink code is actually defined in the client bundle, i.e. when clients add EclipseLink extension code.

Obtaining Proof of Concept

The OSGi proof of concept is being developed in a branch of the EclipseLink Subversion Repository based on EclipseLink 1.0M3. Check out the Proof of Concept page for details on obtaining and running the POC.