Support Article
PRPC63SP1[Engine]Replacing custom jar files in PRPC
SA-2022
Summary
A number of 3rd Party Jar files have been imported into the PRPC installation during a version upgrade (from v5 to v6.3). A proportion of these 3rd Party Jar files need to be upgraded to a newer version. I would like to understand how this would be best performed and some additional technical information. Specifically the following questions:
1. How does the (presumed) PRPC internal classloader function in terms of selecting a version of a class to use? For example if we have an existing library named xmlgraphics-1.2.jar and we wish to replace this with xmlgraphics-1.3.jar, is this possible leaving the files named as they are?. Or will the original have to be removed, or the new version renamed in order to supersede the previous version?
2. What is the procedure for removing imported 3rd party jars from the Pega database, or marking specific instances as redundant?
3. In what circumstance would it be preferable to import 3rd Party jars into PRPC rather than employing the use of a Shared Library as indicated in the PDN? Note that the deployment in question only hosts PRPC, does not share the WebSphere node with other applications, and also has the same 3rd Party Jar files in a shared library attached to the VM.
Resolution
1. How does the (presumed) PRPC internal classloader function in terms of selecting a version of a class to use? For example if we have an existing library named xmlgraphics-1.2.jar and we wish to replace this with xmlgraphics-1.3.jar, is this possible leaving the files named as they are?. Or will the original have to be removed, or the new version renamed in order to supersede the previous version?
Assuming you used the Import Utility to import the custom jar file. During the import, the wizard should provide you option to specify the codeset name and codeset version. When you upload the update version of jar you could specify an updated codeset version with the same codeset name. At runtime, the system will retrieve the most updated codeset version.
2. What is the procedure for removing imported 3rd party jars from the Pega database, or marking specific instances as redundant?
The easiest process is removing from the database. You could retrieve all the jar associated files using the following SQL statement:
select * from pr_engineclasses where pzcodeset = 'your_codeset_name';
Backing up the pr_engineclasses table is strongly recommended.
3. In what circumstance would it be preferable to import 3rd Party jars into PRPC rather than employing the use of a Shared Library as indicated in the PDN? Note that the deployment in question only hosts PRPC, does not share the WebSphere node with other applications, and also has the same 3rd Party Jar files in a shared library attached to the VM.
It is recommended to upload the jar into the database as it is much easier to maintain. One example of this is in a clustered environment where the servers are located in various locations. It can be difficult for the system administrator having to load 3rd Party Jar files onto each node, and then having to remember to make sure to add it whenever any new nodes are added to the system.
4. Are the classes loaded into the 'customer' code set, last in line to be looked at internally - in terms of classloader hierarchy, i.e. 'pega-enginecode' will be looked at first?
The most recently imported module/class will be loaded by the JVM. This is determined by the pzPatchDate attribute in PR_ENGINECLASSES table. If two or more instances of the same class have the same pzPatchDate then the one whose jar name is alphabetically first wins.
5. Secondly does the Pega classloader look for classes internally (in the DB) before going outside to the WebSphere classloader hierarchy - such that for example an shared library would be examined after the database located 'pega-enginecode' and 'customer' codeset classes?
The reason I ask is we have classes such as xerces as dependent entities for our custom code - at specific versions, we need to keep these, while at the same time, not interfering with the versions Pega uses for such things as XML parsing, and use of apache commons libs.
Pega looks at the database first and only if the class is not found does it delegate to the Application Server. There is a (small) list of package names for which it consults the Application Server first - but xml parsers are not part of that list and the list itself is not configurable (requires code change).
In addition, in System Management Application, you can use ETier Runtime Environment Version module to look up Java classes and find out where is is loaded from.
The “ETier Runtime Environment Version module” is located Under the Advanced tab.
Published January 31, 2016 - Updated October 8, 2020
Have a question? Get answers now.
Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.