Page History

...

The other benefit of using classloaders is that you can have isolated components. You could deploy two components (or SU) which use different version of the same library without any problems. This is not possible if you put all the dependencies in the container classpath.

Self-first delegation

...

The common delegation mechanism for classloaders is to delegate to the parent first when loading a class. Thus, all classes defined in the container classloader are shared. But when a class references another class (using an import statement in the Java code for example), the referenced classes will be loaded by the same classloader. To avoid such problems, you can use a self-first delegation where classes are loaded from the classloader, and if not found, it will ask its parent.

Shared libraries and SMX components

To enable self-first delegation for shared libraries and components change the service's POM.XML to include

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.servicemix.tooling</groupId>
      <artifactId>jbi-maven-plugin</artifactId>
      <configuration>
        <classLoaderDelegation>self-first</classLoaderDelegation>
      </configuration>
    </plugin>
  </plugins>
</build>

SU Classloaders

XBean based service units can define their own classloader. This can be done by adding the following tag in the main XBean configuration file for the SU (xbean.xml or servicemix.xml for the servicemix-lwcontainer component):

<classpath [inverse="true"]>
  [<nonOverrideable>xxx<<nonOverridable>xxx</nonOverridable>]*
  [<hidden>xxx</hidden>]*
  [<location>xxx</location>]*
</classpath>

...

The location tag can be used to add jars or directories relative to the SU root to the classloader.

New in ServiceMix 3.1

Starting with ServiceMix 3.1, if no classpath is defined, or if no locations are specified, the default ones will be automatically added in the SU classloader:

...

For ServiceMix 3.0.x versions, you need to define the classpath manually, as the default does not include any locations.

New in ServiceMix 3.2

You can now reference Shared Libraries and Components classloaders using the following syntax:

<classpath [inverse="true"]>
  [<nonOverrideable>xxx<<nonOverridable>xxx</nonOverridable>]*
  [<hidden>xxx</hidden>]*
  [<location>xxx</location>]*
  [<library>xxx</library>]*
  [<component>xxx</component>]*
</classpath>

...

<classpath>
  <library>cxf</library>
  <component>servicemix-wsn2005</component>
</classpath>

New In ServiceMix 3.3.1

You can now reference external archives using system properties. For example:

<classpath>
  <location>${servicemix.home}/lib/ext/my.jar</location>
</classpath>

You can explore and use regex inside externale archives (zip, jar, war, ear). For example:

<classpath>
  <location>jar:file:/path/to/my.ear!/my.jar</location>
  <location>jar:file:/path/to/my.ear!/other*.jar</location>
</classpath>

New in ServiceMix 4.2.0

To allow you to access classes from other OSGi bundles in your SU code as well, the library element has now been enhanced to allow referencing bundles when running in ServiceMix 4.2.0 or above. The URI syntax is osgi:<bundle symbolic name> or osgi:<bundle symbolic name>/<version> to reference a specific bundle version.

Example: the following snippet explicitly adds the org.springframework.bean bundle to the SU classloader.

<classpath>
  <library>osgi:org.springframework.bean</library>
</classpath>