CUBA Class Loading

CUBA relies on the class loading and meta data retrieval mechanisms, provided by the respective runtime environments.

EJB Environment

Running CUBA components as EJBs is the simplest case in the sense that there is actually nothing to mention over the standard. CUBA component modules including generated EJB adapters and descriptors can directly be used as EJB modules and incorporated into EAR files. The application servers are responsible for the retrieval of meta information (application descriptors, module deployment descriptors, and code annotations) and classes. In EJB mode, CUBA doesn't require any resource retrieval beyond the standard, so there's nothing more to know than this.

Stand-alone environment

Using CUBA's wired container for stand-alone applications allows to work with Java's standard system class loader in most cases. In wired mode, CUBA needs to This is usually achieved by simply adding all module archives to the classpath and declare the modules without path in the application descriptor. The wired-application.xml must also be loadable from a library or a directory on the CLASSPATH.
If you produce large wired applications you may run into problems with a growing classpath. E.g. on older Windows platforms, both environment variables and command lines are limited to 1024 characters and may cause problems when working with 20 separate component modules or more. For these cases, CUBA provides the alternative class DDClassLoader which allows to address the component modules indirectly. The class loader reads module names from the application descriptor and tries to locate them in all directories specified on the classpath. This allows e.g. to put all modules in a single directory and specify only this directory on the classpath. Beside component modules, the class loader also allows to located ordinary libraries in the same way using the java element in the wired-application.xml, e.g.:
 
<?xml version="1.0" encoding="UTF-8"?>
<wired-application>
  <modules>
    <wired>mycomponent.jar</wired>
    <java>mylibrary.jar</java>
  </modules>
</wired-application>

The DDClassLoader is assumed to be used as system class loader being specified by system property java.system.class.loader. Of course, at least the wired-application.xml must be available through the default system class loader or any of its parents.

Servlet environment

Servlet engines like Tomcat are a kind of managed environment and include their own class loader hierarchy to fullfil the servlet specification. The application class loader allows to retrieve classes and other resources from either the WEB-INF/classes directory or from any library file in the WEB-INF/lib directory. Using the wired container in a servlet environment is therefore very simple. The component modules and any other libraries (at least the CUBA runtime library, of course) are copied to the WEB-INF/lib directory. For the wired-application.xml, simply create the directory WEB-INF/classes/META-INF and copy the file into it.

AXIS environment

Usually, an AXIS environment is nothing else but an ordinary web application in a servlet engine. I.e. there apply the same rules as above. That's it :-)

Home Introduction Javadoc