How does the Deployment Engine resolve classes in IBM Tivoli Provisioning Manager?
If you are working on writing custom java helpers, this information could be useful to your work.
There is one main difference between running a simple java application (either spawning a new JVM from a scriptlet in TPM or running java from the command line) and running the java helper from a workflow: The deployment engine uses OSGi runtime to load the classes and run them. That means the helper classes are not loaded by the system/application classloader, but they are loaded at runtime by the bundle classloader when they are invoked by a workflow.
There are couple of classloaders we use in TPM engines (LWI based):
1. system or application classloader - this is the LWI classloader and it contains all the classes that are required to run LWI/OSGi runtime.
2. TPM engines classloader - this the classloader used by TPM engines to start MXServer and all the required engines (deployment engine, activity plan engine, cli service, and so on). This is basically the classloader of the tpm_pmp bundle and this bundle depends on most of our projects. You can say this classloader contains all the classes in TPM.
3. workflow classes classloader - our custom URL classloader that loads all the generated workflow classes. It's also used to weave the generated classes and inject byte code at runtime for different types of events (i.e. start/end workflow, start/end scriptlet invocation)
4. bundle classloader - when a workflow invokes a java class/helper, the class is loaded using the tcdriver bundle classloader that the workflow belongs to. Probably this is the most interesting classloader as it depends on the tcdriver's manifest definition (you need to check the Bundle-classpath section of the manifest to determine what classes/jars are loaded in this classloader).