Utilities › Invoke Java Operator › Input Parameters › Code

Code

List External Jar Paths?

Select to provide a list of paths to the required external JARS in the External Jar Paths as Expression field.

Clear to provide the paths to the required external JARs as an expression, that is, as a dataset variable in the External Jar Paths as Expression field.

This check box is selected by default.

External Jar Paths

Specifies the list of paths to the external JARs that are required by the main method code of the operator, if any.

The Invoke Java operator loads the JARs listed in this field. Any JAR entered in this list is available to the Java code executed by the operator. The classes defined in the operator-level JARs override the same classes specified in the JARs at the operator category level.

For each path, you can:

• Enter the full path to a JAR file that resides on the host where the CA Process Automation agent (mapped to the touchpoint) is running. The full path is specified as follows:
  • Starts with: /
  • Starts with: \\
  • Of the form: ^.:.* (a regular expression that starts with one character followed by a colon - : - and then the rest of the string.)
• Enter the path to a JAR file that is downloadable over HTTP. Verify that the HTTP path does not require authentication and is not through an HTTP proxy. The path to the JAR must start with http:// or https://.
• Any other path is assumed to be a relative path to a JAR file that was uploaded in the CA Process Automation user resources. CA Process Automation appends the JAR file path to the path of the "CA Process Automation User Resources" directory of the agent (that is mapped to the touchpoint) running the operator.

  Do not start the JAR file relative path with:

  • /
  • \\

  Otherwise, CA Process Automation assumes that the JAR file path is a full path.

Resources within CA Process Automation, including user resources, are mirrored within the mirroring interval of the agent. Verify that the JARs uploaded in the user resources are already mirrored before using them in the Invoke Java operator.

Class Files

In addition to external JARS, you could load .class files as follows:

• For .class files in an unnamed package, enter a path that ends with the directory that contains the .class files.

  For example, if MyAccount.java does not belong to a package, and MyAccount.class is located at:

  C:\java\tests\MyAccount.class

  ...then set the operator to use the following path:

  C:\\java\\tests

• For .class files in a named package, enter a path that ends with the directory that contains the "root" package. This package is also known as the first package in the full package name.

  For example, if MyAccount.java belongs to package com.ca.tech, and MyAccount .class is located at: C:\java\othertests\com\ca\tech\MyAccount.class

  ...then set the operator to use the following path:

  C:\\java\\othertests

If you specify the path to a directory (to load .class files), enter it as a full path. You can also enter it as a relative path to CA Process Automation User Resources. Do not enter the path as an HTTP path.

Specify the path to a directory to load .class files, not JAR files. Unlike .class files, each JAR file requires a separate path that ends with the JAR file (not the directory where it resides).

External Jar Paths as Expression

Specifies the indexed string dataset variable that contains the list of paths to the external JARs required by the main method code of the operator, if any.

Enter Required Main Method?

Select to provide the Java code in the Required Main Method field.

Clear to provide the Java code as a dataset variable in the Required Main Method as Expression field.

This check box is selected by default.

Required Main Method

Specifies the Java code text of the main method. You can browse to locate any file that contains this code. The main method consists of normal Java statements and expressions. You must initialize and use objects defined in the Java SDK or the external JARs.

Note: CA Process Automation parses the code and checks for its structural validation when you click OK. An error message displays if an error is found in the structure of the code.

See Java Code in the Invoke Java Operator.

Required Main Method as Expression

Specifies the dataset variable that contains the content of the main method. The main method consists of normal Java statements and expressions. You must initialize and use objects defined in the Java SDK or the external JARs. No structural validation is performed.

See Java Code in the Invoke Java Operator.

Set Context Class Loader?

Set this field (to something different than default) if your main method/external JARs rely on the Java context class loader to load classes. Set the Java context class loader to either the operator class loader or the module class loader to avoid a ClassCastException.

The Invoke Java operator uses a chain of class loaders to load classes while running the Java code. This chain was designed as follows (among other class loaders):

1. Operator Class Loader: class loader that loads the classes provided at the operator level
2. Module Class Loader: class loader that loads the classes provided at the module level
3. Context Class Loader
4. Regular java Class.ForName

The operator consults each class loader before moving to the next (if the class is not found).

This chain works as long as the code that you execute does not explicitly use its own class loader to load a class. In this case, you see in the logs a 'ClassCastException'.

Example:

Consider class MyChildXMLParser extends class MyParentXMLParser. The following code fragment listed creates a MyParentXMLParser by using a Java factory. This factory actually loads and creates a MyChildXMLParser, which is then cast into a MyParentXMLParser object:

public MyParentXMLParser() {
        super((MyParentXMLParser)ObjectFactory.createObject("com.ca.parser.MyChildXMLParser"));
          ....
     }

In this example, consider:

• The ObjectFactory.createObject() method actually calls its own class loader to load the MyChildXMLParser class. This behavior is typical of Java factories, where they either use the system class loader, or (if it exists) a context class loader to load the class (instead of using the class loader that is used by the executing program).
• The MyParentXMLParser class is loaded by the Invoke Java operator's class loader (as selected using the previous chain.)
• The cast: ((MyParentXMLParser)ObjectFactory.createObject) throws a ClassCastException. Although MyChildXMLParser extends MyParentXMLParser, the two classes were loaded by different class loaders. As a result, they are completely different from each other.

To resolve this issue, set the field ‘Set Context Class Loader’ to either:

• "1 : Operator class loader": If the jar that contains ‘MyChildXMLParser’ and ‘MyParentXMLParser’ classes is provided in the operator properties.
• "2 : Module class loader": If the jar that contains ‘MyChildXMLParser’ and ‘MyParentXMLParser’ classes is provided in the module properties.

Note: "0 : Default" is used in all other cases where your Java code does not explicitly load classes using its own class loader. This value is the default value of this field.

By setting the context class loader to the class loader of the Invoke Java operator, the Java factories that are called by the user’s code are forced to use the Invoke Java operator class loader. This action removes ClassCastException.