SR-C98068 · Issue 483991
Installer files updated with class loader conflict resolution assistance
Resolved in Pega Version 8.2.4
When sending emails with attachments, errors were observed relating to a loader constraint violation indicating that when resolving interface method, the class loader of the current class and the class loader for the method's defining class had different Class objects for the type used in the signature. The resolution for this requires user configuration of the app server, and the following files for the install guide have been updated with the appropriate information:Deployment-guides-dita/install.ditamap Deployment-guides-dita/Content/Topics/app-server-config/creating-jdbc-driver-module-jboss-tsk.dita Deployment-guides-dita/Content/Topics/app-server-config/delegating-javax-activation-to-JRE-loader-tsk.dita
SR-D28460 · Issue 509365
Added timeout handling for non-PRAuth servlets
Resolved in Pega Version 8.2.4
After logging in via external authentication service (SAML Single Sign On) and setting up a timeout in the access group RuleForm, when the user performed any action and the server identified the request to be timed-out, it was expected that a SAML request would be sent from the browser to the external Authentication Server (referred as IDP) and the flow would proceed from there. This worked as expected for a non-AJAX request. To resolve this, handling has been added for timeout when using non-PRAuth authentication services.
SR-D29127 · Issue 506863
SAML data pages restored after passivation
Resolved in Pega Version 8.2.4
If login used SAML SSO, resuming the session after passivation resulted in missing or empty data pages when using an SAP integration with Pega Cloud. This was traced to a security change that modified the D_SAMLAssertionDataPage and D_SamlSsoLoginInfo data pages as readonly, causing them to not be passivated under these conditions. To resolve this, the data pages have been made editable so they will be restored as expected. This change also resolves any difficulty with SAML logoff activities in conjunction with SAP and Pega Cloud.
SR-D37872 · Issue 507341
prproductmigration build.gradle updated for new mime4j asset name
Resolved in Pega Version 8.2.4
While running the getMigrationLog for ProductMigration script provided in the Pega 8.2.2 media files, errors appeared referencing "NoClassDefFoundErrors when running getLogs". This was caused by the referenced class not being found on the classpath: the version of the included jar did not include the class needed due to Praxiom's default version being updated to use a new version of mime4j that required an asset name change. To resolve this, the mime4j asset name in prproductmigration build.gradle has been updated to pick up the correct version of the dependency for Praxiom.
SR-132637 · Issue 203591
Added path checking to FirstLogCreationTime.log
Resolved in Pega Version 7.1.9
FirstLogCreationTime.log was being written to a temp folder using hard-coded logic to use a relative path within the install directory. This caused errors if the installer was trying to write the logs in an absolute path. FirstLogCreationTime.log should be written to the same directory as the rest of the logs, and this issue has been fixed by adding a condition in LogDeleteUtil.getLogCreationTimeFile() method to check for absolute paths.
SR-133747 · Issue 203813
Corrected hashtag handling for Oracle SQL generation
Resolved in Pega Version 7.1.9
Given a column name with a hashtag in an Oracle environment, the system was compiling SQL statements which caused ORA-00904 errors due to replacing the # in one variable name with an _ but leaving it as a # in another. This has been corrected.
SR-133057 · Issue 205124
System updated to better handle multi-node rule resolution
Resolved in Pega Version 7.1.9
In an upgraded multi-node environment, the error 'com.pega.pegarules.pub.database.MultipleRuleVersionException: Rule resolution identified 2 versions of the rule' was sporadically appearing. Once the issue occurred, it would persist and the only way to resolve it was to bounce the server. This was an issue with an instance of one rule being found in one node and not found in other node, and was related to the trigger logic. This should not occur with the current Pega7 version, as trigger logic has been moved into the engine and there is no longer a database trigger to fix. In order to ensure continued smooth trigger resolution, tests have been added that will check for this condition in the updates cache table to ensure that this scenario does not occur again
SR-A1479 · Issue 205900
UpgradeDataSchema target sets resume.action correctly
Resolved in Pega Version 7.1.9
Attempting to resume an upgrade after correcting a local error failed due to resume.properties having the default resume.action=install instead of =upgrade, causing the system to attempt to create tables in the data schema which already existed. The default of "install" that is set for resume mode has been removed, and the install process will now specifically set it when appropriate. A check has also been added to ensure the flag is set properly for the work being done.
SR-A1479 · Issue 205896
UpgradeDataSchema target sets resume.action correctly
Resolved in Pega Version 7.1.9
Attempting to resume an upgrade after correcting a local error failed due to resume.properties having the default resume.action=install instead of =upgrade, causing the system to attempt to create tables in the data schema which already existed. The default of "install" that is set for resume mode has been removed, and the install process will now specifically set it when appropriate. A check has also been added to ensure the flag is set properly for the work being done.
SR-A1479 · Issue 205895
UpgradeDataSchema target sets resume.action correctly
Resolved in Pega Version 7.1.9
Attempting to resume an upgrade after correcting a local error failed due to resume.properties having the default resume.action=install instead of =upgrade, causing the system to attempt to create tables in the data schema which already existed. The default of "install" that is set for resume mode has been removed, and the install process will now specifically set it when appropriate. A check has also been added to ensure the flag is set properly for the work being done.