Defining Start Up Classes
Important: You may want to limit access to the StartUp folder to prevent the addition of malicious code.
TeamConnect finishes its standard initialization before it executes the class files in the StartUp folder. Your custom code can affect TeamConnect's initialization after its standard initialization and before TeamConnect becomes available via a web browser.
Note: Custom code may not be compatible across TeamConnect releases.
Start Up Settings
Use the web.xml file to update settings for the StartUp folder. To enable the execution of custom code in the StartUp folder, set the app.runStartUp application parameter to YES in the web.xml file. To stop the execution of all class files in the StartUp folder in the event of any runtime errors or exceptions, set the app.runStartUp.failOnError parameter to YES in the web.xml file.
How TeamConnect Uses Start Up Classes
By default, the system user executes the start up classes. TeamConnect executes classes in the
StartUp folder under the following conditions:
- The files must be Java classes. TeamConnect ignores non-Java class files and any sub-folders in the StartUp folder, unless you reference them from the Java class. For example, you can include JAR files and reference them from class files.
- The Java classes must include implement the
ScheduledCustomActioninterface and the method of
public void action()to hold the action to run. If you set the system logging level to Info or Debug and upload Java classes that do not implement the
ScheduledCustomActioninterface, TeamConnect logs the following message and continues to the next java class:
ClassName does not implement TCStartUpAction or ScheduledCustomAction. Not running ClassName.
- In the alphabetical order of the file names if multiple class files are present in the StartUp folder.