install

This package provides routines that allow service packages to be dynamically installed.

• 
  This installs a number of Java classes to be made available as services on the invoking node. Each element of the input list is a pair whose first element is the name of the class to be installed, and whose second element is the bytecode file defining that class (this could have been obtained on the injecting host using getBlobFromFile; see below). Elements of this list may be specified in any order, and classes may mutually reference each other. All classes to be installed will be dynamically linked with the other classes in the list as well as those on the invoking router. In other words, if class A is being installed, and it refers to class B, then class B must be present elsewhere in the input list, or it must already be loaded on the router.

  The way this function works is as follows. First, each class is loaded (in the Java sense of the word) to become part of the active router. Next, the install method, if present, in each class is invoked. This method should take as its argument a SymbolTable object, which is used by install to store the bindings of service functions to be made available to PLAN programs. Refer to the source file install/InstallSvcImpl.pizza for a template for writing an install routine.

  If a failure occurs during this process, a diagnostic will be printed to the router console, and the exception BadService will be raised.

  Because of a limitation in the JDK 1.1, classes may not be unloaded and therefore only one version of a class may ever be loaded dynamically; to install a new version of a service, the router must be halted and restarted, and then the new version of the service may be loaded. This problem should be rectified in future versions of PLAN (either by inheriting the fix from an newer version of Java or by some other means).

  An obvious side-effect of this service is that loaded classes will consume memory on the active router, a fact that could be maliciously or inadvertently exploited. This problem is exacerbated by the fact that classes can never be unloaded. Therefore, we anticipate that future releases of PLAN will require authentication before allowing a PLAN program to dynamically load services.