SR-C72385 · Issue 414867
Resolved ClassCast email exception caused by duplicate javamail class loading
Resolved in Pega Version 8.2
A ClassCastException was occurring when attempting to configure an email account in conjunction with JBOSS , WebLogic, or WebSphere Liberty. Analysis traced the issue to Class Loading: the WAS application server was providing a default com.ibm.ws.prereq.javamail.jar which conflicted with Pega's out of the box mail-1.5.5.jar, and at run time the JAR provided by WAS was getting picked due to JBoss, Weblogic, and WAS loading architectures from Tomcat. To resolve this, the delegation in PRAppLoader has been expanded to include the "javax.mail." package. This will ensure that Pega delegates to the web-app classloader unconditionally for the email classes. This prevents the ClassCastException caused by the interface javax.mail.Transport and com.sun.smtp.(Implementation Class) being loaded by two different class loaders.
SR-C77994 · Issue 419283
Resolved ClassCast email exception caused by duplicate javamail class loading
Resolved in Pega Version 8.2
A ClassCastException was occurring when attempting to configure an email account in conjunction with JBOSS , WebLogic, or WebSphere Liberty. Analysis traced the issue to Class Loading: the WAS application server was providing a default com.ibm.ws.prereq.javamail.jar which conflicted with Pega's out of the box mail-1.5.5.jar, and at run time the JAR provided by WAS was getting picked due to JBoss, Weblogic, and WAS loading architectures from Tomcat. To resolve this, the delegation in PRAppLoader has been expanded to include the "javax.mail." package. This will ensure that Pega delegates to the web-app classloader unconditionally for the email classes. This prevents the ClassCastException caused by the interface javax.mail.Transport and com.sun.smtp.(Implementation Class) being loaded by two different class loaders.
SR-D85745 · Issue 545906
DASS and DAS associated to the Pega-ProcessCommander Ruleset
Resolved in Pega Version 8.4.1
An upgrade was failing at the point of Pega Rules Upgrade in the Installer Instance with the error "Encountered database exception when preprocessing deferred operations <insert updatesCache instance DATA-ADMIN-SYSTEM PEGA not only if new>. This node not found in the database - Either the record was never saved or was deleted. Unable to join the cluster." This error occurred because the strategic application import during upgrade manually included a "systemname" DASS instance which had a value other than "prpc". This caused a override of the platform shipped DASS (with value "prpc), which is required by the upgrade. In order to avoid this condition, DASS and DAS have been associated to the Pega-ProcessCommander Ruleset.
SR-D68707 · Issue 529871
Update Handler will not run during migration
Resolved in Pega Version 8.4.1
Rolling restart of DataFlow, ADM ,VBD, and Util Tiers failed with a PENDING_JOINING error after an in-place upgrade. This was traced to the logic for the update timing: when nodes start after an upgrade from 7.x to 8.x they will migrate data flow runs. Migration happens on only one node, and while it's in progress the other nodes will wait until migration finishes before they come up. At this point the state of the data flow services will be 'PENDING JOINING'. The issue is that while migrating runs, the Data Flow Update Handler was triggered to validate whether there were nodes available on the service the run belongs to. This call can cause the corresponding data flow service to be initialized, but the call will be blocked since all services wait for the migration to end. This resulted in a deadlock which prevented all nodes from coming up successfully. To resolve this, the process has been updated to skip the update handler during migration to avoid triggering the initialization of client services that are waiting on the migration lock.