A Processing Unit should follow a certain directory structure in order that it can be deployed with Processing Unit containers.
Processing Units are deployed into the <GigaSpaces Root>\deploy directory on the GSM, which contains the following:
Your classes with their respective packages, for example, <GigaSpaces Root>\deploy\mypu\com\myco\GSTest.class.
META-INF\spring contains the pu.xml file (Spring configuration file, defining the Processing Unit for all components).
The lib directory is intended for Processing Unit-specific JARs.
This directory uses a Processing Unit-specific classloader (you can undeploy the Processing Unit, update a JAR file in the lib directory, and then redeploy).
You cannot share the class between two different spaces; if a class needs to be shared, place it in shared-lib.
The shared-lib directory is intended for JARs that are shared between Processing Units.
This directory places all classes in the common class loader and they will be shared by all running processing units. For example, Entries (classes that are used with the Space), remoting parameters, and the remoting interface must reside within the shared-lib.
Here is an example of a Processing Unit (loosely based on the data example):
The above example shows a Processing Unit directory composed of several sections:
The first is the META-INF section, which includes the Spring context XML configuration called pu.xml (this is the default location of the Spring configuration used by all containers).
The second section is the Processing Unit application class files, which exist directly under the Processing Unit root directory.
The third section includes third party jar files that are used only by the Processing Unit. The example shows commons math which might be used for different mathematical computations.
The fourth section includes jar files that are shared between the Processing Unit and other Processing Units or spaces. In the above example, the data-common.jar includes the domain model written to the space, and a shared interface (when using OpenSpaces remoting) between the processor PU and the feeder PU.
The standalone container and Service Grid container support the above structure. The integrated container has a sensible default only for the pu.xml location (which can be overridden) which follows the above structure. The rest is assumed to be configured externally.
Enterprise Data Grid Space Template Processing Unit
When launching a space via the Service Grid (the space is deployed onto a GSC, but isn't associated with a user-defined Processing Unit), the space is contained within a template Processing Unit: <GigaSpaces Root>\deploy\templates\datagrid.
The datagrid template Processing Unit can be copied to the deployment folder and deployed as a space.
For example, a third-party driver can be placed in the <GigaSpaces Root>\lib\ext folder, or in the <GigaSpaces Root>\deploy\templates\datagrid\shared-lib folder.
As a best practice, when deploying spaces, always copy the <GigaSpaces Root>\deploy\templates\datagrid folder to a new folder (<GigaSpaces Root>\deploy\myCluster), and place a pu.xml file with all relevant decorations there.