User Code Namespaces

5.5-SNAPSHOT 5.4 5.3 5.2 5.1 5.0

User Code Namespaces provide a container for Java classpath resources, such as user code and accompanying artifacts like property files. This provides namespace isolation to ensure that access to resources in different namespaces can be managed through configuration.

This approach replaces the deprecated User Code Deployment method of adding your resources to make them available for your user-defined functions. For information on migrating your User Code Deployment to User Code Namespaces, see the Migrate from User Code Deployment topic. The original User Code Deployment information has been retained to support your migration in the User Code Deployment section.

Your resources can be run on a Hazelcast cluster to support your business logic. For example, you might want to use your resources in one of the following:

  • MapStore

  • Split brain events

  • ExecutorService runnable

To use User Code Namespaces, you must enable it as described in the Enable User Code Namespaces topic.

User-defined functions are associated with User Code Namespaces using the namespace names. Named data structures each define a single namespace name; you can configure the same namespace name for multiple data structures. You can also configure the default namespace; for example, to provide resources for a user-defined function that is not associated with a data structure. For further information on the default namespace, see the Non-associated Namespaces topic. Your resources are located using an URL. For example, your resources could be located on your member or client with an URL such as file:///opt/hz/lib/calc.jar or classpath:///com/acme/myClass.

If your data structure is associated with a namespace that has not been configured, a fatal error is returned when an operation is performed on that data structure.

You can configure User Code Namespaces in the following ways:

  • Static. This configuration must exist on start-up and is defined using XML or YAML files, or programmatically. For further information on static configuration, see the Static Configuration section

  • Dynamic. This configuration allows you to deploy resources from your client. This method allows you to update your User Code Namespaces at runtime, which means that the next call for a data structure associated with the namespace uses the updated resources. For further information on dynamic configuration, see the Dynamic Configuration API section

    When using dynamic configuration, long-running executions are not restarted and continue to use the previous namespace resources until you manually restart them.

    You can define resources in your dynamic configuration as follows:

    Resource Description

    Class

    Use to deploy a single Java class instance; for example MyEntryProcessor.class. This is the best way to deploy a small amount of code, in a single class, from your application class path to the cluster.

    JAR

    Use to to deploy a single JAR file; for example, All_Entry_processors.jar. You can include additional dependencies using shading when the JAR is produced. This is the best way to package non-trivial code for deployment.

    JARS IN ZIP

    Use to deploy a ZIP containing multiple JAR files; for example, All_Entry_Processors.zip. This is the best way to package JAR files and dependencies for larger deployments, or where additional dependencies are used without repackaging.

You can define different User Code Namespaces by providing a name and the URLs used to locate the resources. Multiple data structures can reference the same namespace.

You can follow the provided code examples to support your use of the API configuration, as described in the Code Samples GitHub repo.