classpath

• Overview
• Attributes
• Child Elements
• Rendering Operations
• Examples
• Classloader Hierarchy

Overview

The <classpath> element allows defining the classpath of a Java application. It provides a convenient and elegant way to declare what are the files or resource directories that are needed as part of an application's classpath.

An interesting feature is that you can create a hierarchy of <classpath> elements - and therefore classloaders. Using the id and the parent attributes, a child classpath can refer to a parent classpath. This gives you the possibility to organize your resources for reuse, provides the flexibility to manage the Java classloader hierarchy of your application. You could even have more than one application as part of the same Magnet configuration that share a common classpath, yet have their own one (more on classloader hierarchies further below).

Attributes

The following lists the xml attributes of the classpath element:

Child Elements

The following lists the possible child xml elements the classpath element can hold:

Rendering Operations

When a <classpath> element is rendered, it performs the following operations in order:

1. Resolves the id and parent attributes (using variable interpolation).
2. Renders all the <path> child elements.

Examples

This first example shows a classpath element that will contains all the jar files from the ${user.dir}/lib directory:

<magnet xmlns:magnet="http://schemas.sapia-oss.org/magnet/"
        name="ClasspathExample1"
        description="This is a first classpath example.">
...
    <classpath>
        <path directory="${user.dir}/libs">
            <include pattern="*.jar" />
        </path>
    </classpath>
...
</magnet>

This second example creates a simple classpath hierarchy with a first 'api-libs' classpath that contains all the jar files of the ${user.dir}/api-interfaces directory and an 'app-libs' child classpath that contains the directory ${user.dir}/config/ (for easy access to configuration files) and all the jar files of the ${user.dir}/app-libs directory:

<magnet xmlns:magnet="http://schemas.sapia-oss.org/magnet/"
        name="ClasspathExample2"
        description="This is a second classpath example.">
...
    <classpath id="api-libs">
        <path directory="${user.dir}/api-interfaces">
            <include pattern="*.jar" />
        </path>
    </classpath>

    <classpath id="app-libs" parent="api-libs">
        <path directory="${user.dir}/config/">
        <path directory="${user.dir}/app-libs">
            <include pattern="*.jar" />
        </path>
    </classpath>
...
</magnet>

Classloader Hierarchy

It is important to mention that Magnet will keep a one-to-one relationship between a classpath element and a Java classloader. When a hierarchy of classpath elements is created in your Magnet configuration file, the same classloader hierarchy will be created in the JVM's memory. Magnet will use the system classloader of the JVM as the root of the classloader hierarchy.

This gives the flexibility to the programmer to decide what is the scope of the classes used when launching Java applications(especially when launching more than one application in a single JVM). It also gives an elegant way to workaround classloading issues that can arise when using third party tools.