17.3.3 Notes about implementing user functions
The following notes apply to implementing user functions.
-
Set the access qualifier of the default constructor of user functions to public so that it can be used by the EADS servers.
-
Use serializable objects for the arguments and the return value from the EADS client.
-
If you acquire data by using the Group interface, use one of the following methods to add to the class path the information needed to deserialize objects:
-
Specify the path of the jar file in the Class-Path attribute of the jar manifest.
-
Place the jar file under the management-directory/app/lib directory.
-
-
Only one instance of a user function is supported. If multiple instances of a user function are executed concurrently on multiple EADS clients, the EADS servers attempt to use the same instance in multiple threads. Therefore, do not implement the following processes in the user functions:
-
Updating instance variables and the static variable without locking
-
Using an API function that is not thread-safe without locking
-
-
The scope of FunctionContext and the objects that can be acquired from it is only within the Function interface's methods. Operation is not guaranteed if these objects are referenced outside the range of those methods.
-
Do not create threads within a user function. Operation is not guaranteed if threads are created and executed within a user function.
-
Because user functions are run in an EADS server processes, the current directory is the management directory.
-
When user functions are executed from C client application programs, the only objects that can be handled as user function return values are byte arrays and null. An error will result if an object that is not a byte array or null is set as a return value.
-
When user function arguments are passed to C client application programs, the only objects supported by the user functions are byte arrays.