jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger" <fmesc...@gmail.com>
Subject Custom ClassLoader for BeanConfig
Date Fri, 28 Jul 2006 06:41:22 GMT
Hi all,

I am trying to develop OSGi (http://www.osgi.org) bundles from
Jackrabbit repository parts. So for example, I will define a bundle
for the core Jackrabbit Repository and separate bundles for extensions
like SearchHandlers or PersistenceManagers. As OSGi specifies class
loading rather strictly this requires special handling for loading
those extension classes.

Currently these classes configured in repository.xml and workspace.xml
files are loaded through the BeanConfig.newInstance() method using the
ClassLoader of the BundleConfig class. This works very well as long as
all configured classes are accessible throught that class loader. For
OSGi bundles this is generally not the case.

Hence, I thought that making the class loader to use by the BeanConfig
class configurable by extending the class with these methods:

public class BeanConfig {
  // Current default class loader, default is BeanConfig's class loader
  private static ClassLoader defaultClassLoader =
  // Current instance class loader
  private ClassLoader classLoader;
  // Sets the default class loader for new BeanConfig instances
  public static void setDefaultClassLoader(ClassLoader loader);
  // Returns the default class loader for new BeanConfig instances
  public static ClassLoader getClassLoader();
  // Sets the class loader of this BeanConfig instance
  public void setClassLoader(ClassLoader loader);
  // Returns the class loader of this BeanConfig instance
  public ClassLoader getClassLoader();

The BeanConfig.newInstance method would then use the following to use the class:

public Object newInstance() throws ConfigurationException {
  Class clazz = Class.forName(getClassName(), true, getClassLoader());

A third modification concerns the RepositoryConfig class: This class
does not currently extend the BeanConfig class. To also support this
class loading functionality for the RepositoryConfig class, I suggest
having this class extend BeanConfig, too. While it might not provide
anything more than this, it would probably also not hurt, would it ?

What do you think of this enhancement ?


View raw message