About this task
To build your custom code extensions (user exits, extended
APIs, custom implementations of supplied Java™ interfaces,
and so forth) modifications, generate a JAR file containing these Java files and custom classes. After
creating the JAR file, include the new JAR file in the CLASSPATH environment
variable by running the install3rdParty.sh (or install3rdParty.cmd
on Windows) utility from
the <INSTALL_DIR>/bin directory. For
example:
./install3rdParty.sh <vendorName> <vendorVersion> <-j
| -l | -p | -r | -d > <filelist> [-targetJVM
DCL | EVERY | NOWHERE | APP | AGENT]
Here, <vendorName> refers
to the name of the vendor such as WebLogic, WebSphere®, and JBoss. <vendorVersion> refers
to the version of the vendor. Pass the appropriate argument based
on the file type. You can pass the following arguments:
- -j for JAR or compressed files
- -l for shared libraries
- -p for properties files
- -r for resource properties files
- -d for database JAR or compressed files
<filelist> refers to the path to
your custom file.
Note: If you want to make this
custom JAR available to the application server and agents when running
the install3rdParty utility, based on your requirement pass the following
target JVM arguments:
- DCL—If you want to add the custom JAR to the main dynamic
classpath.cfg file only.
- EVERY—If you want to add the custom JAR to all the dynamic
classpath files (for example, APPDynamicclasspath.cfg, A GENTDynamicclasspath.cfg
, OPSDynamicclasspath.cfg, and ACTIVEMQDynamicclasspath.cfgfiles).
- NOWHERE—If you just want to add the custom JAR to the <INSTALL_DIR>/jar
directory and do not want to update any of the dynamic classpath files.
- AGENT—If you want to add the custom JAR to the AGENTDynamicclasspath.cfg
file.
- APP—If you want to add the custom JAR to the EAR file.
For example, if you want to add the custom JAR
to the AGENTDynamicclasspath.cfg file, run the install3rdparty command
with following arguments:
./install3rdParty.sh weblogic
12.1.2 -j <Path_to_your_custom_JAR> -targetJVM
AGENT
Note: At times, mechanisms supplied
by Sterling Selling and Fulfillment
Foundation,
such as time-triggered transactions, APIs, and user exits, are replaced
by improved mechanisms. When these mechanism are replaced, they are
designated as “deprecated.” Whenever possible, use the
new mechanisms rather than the deprecated ones. If you do need to
use a deprecated mechanism, it must be run in backward compatibility
mode. In addition, note that deprecated mechanisms are supported for
two major software versions, and then they are removed from the product.