JDK Versions for MI | Import a .war file into a new project
MI Client has its own class loader (that is, a class that implement a java.lang.ClassLoader). This class loader takes precedence over Tomcat's class loaders. This chapter describes
A class loader is an object that is responsible for loading classes. Given the name of a class, it should attempt to locate or generate data that constitutes a definition for the class. A typical strategy is to transform the name into a file name and then read a "class file" of that name from a file system.
Applications (like MI or Tomcat) implement subclasses of java.lang.ClassLoader in order to extend the manner in which the Java virtual machine dynamically loads classes.
![]() |
For more information on class loaders, please consult the Java doc for java.lang.Classloader at http://java.sun.com. |
MI Client can be looked at as the server for all mobile applications: MI controls the entire life-cycle of a mobile application and thus installs, starts, stops, de installs applications, synchronizes application data etc. In order to offer these framework services, MI needs to control which application and framework classes are loaded. As MI for JSP is based on Tomcat 3.2.4, we need to look closely at Tomcat's class loaders to describe why Tomcat's class loading strategy is not sufficient for MI's purposes.
In Tomcat, a class loader is created for each web application that is deployed under <TOMCAT_HOME>/webapps. All unpacked classes and resources in the /WEB-INF/classes directory of your web application archive, plus classes and resources in JAR files under the /WEB-INF/lib directory of your web application archive, are made visible to the containing web application, but to no others.
This means that the web application class loader diverges from the default delegation model for class loaders: When a request to load a class from the web application's class loader is processed, this class loader will look in the local repositories first, instead of delegating before looking.
From Tomcat's perspective, MI is only another web application (and has therefore its own sub folder <ME_HOME>/webapps/me). Tomcat would thus disallow MI to call other web applications - this obviously makes it impossible to offer the above-mentioned framework services. If, for example, inbound containers for a mobile applications are received by MI, they need to be dispatched to the application that is responsible for their processing. When Tomcat does not allow MI to call other applications, this would obviously not work.
We can therefore say: "In order to be a framework for mobile applications, MI needs to have its own class loader that takes precedence over Tomcat's class loaders".
MI's class loader loads classes in the following sequence:
The order in which the applications appear in above loop is not defined.
This load sequence has very important implications:
![]() |
The MI classloader is only used, if MI is using JDK 1.3.*. If MI is using JDK 1.1.8, Tomcat's class loader will be used by MI for JSP. MI for AWT will use the JVM default class loader. This implies that inbound containers of applications that have not yet been started will not be processed. They will be discarded and automatically be resent by the WebAS on next synchronization. A corresponding error message will appear in the trace file. |
![]() |
MI for AWT is also using the MI class loader (if MI is running on 1.3.*). As there is no webapps folder for AWT, all archives are loaded in the order in which they appear in file <ME_HOME>/listOfJars.txt. In MI for AWT, this file contains the libraries for framework and applications. |
![]() |
The MI class loader does not only load classes, but any file that can be loaded via method getResourceAsStream(), as property files, images etc. |
Application developers need to be aware of the implications of the class load sequence described above:
![]() |
Eclipse does NOT automatically update references to classes or packages in JSP or web.xml. They need to be adjusted manually. |