Code Deployment

CodePools are the basic unit for Dynamic code deployment.
There are two ways of deploying code to workers:

• compile your code and put your JARs in the "extra" directory of each worker
• create a CodePool and assign it to your tasks

A CodePool is essentially a bunch of JAR files packaged as a ZIP file which will be put in the classpath of the code which execute the task.

The best way to create CodePools is to use the TaskSubmitter utilty.

See this file for a simple example:
https://github.com/majordodo/Majordodo/blob/0.2.0/majordodo-test-clients/src/main/java/majordodo/testclients/TaskSubmissionExample.java

Task Submission

Task submission can happen in these "modes":

• mode=factory: the worker will look for a TaskExecutionFactory in the "extra" classpath, this in turn will create TaskExecutors
• mode=object: the worker will consider the "data" payload of the Task in order to instantiate a TaskExecutor

With mode=object the TaskExecutor will be interpreted in this way:

• if the data field starts with base64 then the rest of the string will be treated as a base64 encoded stream which contains the JDK serialized TaskExecutor
• if the data field starts with newinstance: then the rest of the string will be treated as a class name, and the Worker will instantiate a TaskExecutor using Class.forName(...).newInstance

With mode=object the worker will instantiate the TaskExecutor using a classloader choosen in this way:

• if the task is assigned to a CodePool then the TaskExecutor will be created using the CodePool Classloader (which contains CodePool Jars, the "extra" libs and the "system" libs)
• if the task is not assigned to a CodePool then the TaskExecutor will be created using the "extra" libs and the "system" libs

It is always advised to put your custom classes in the "extra" directory and not in the 'lib' directory in order to handle easy upgrades. In fact upgrade is usually done by replacing the contents of the the "lib" directory and leaving untouched the "extra" directory.