OUAF Release 4.0.2.0
com.splwg.base.support.FrameworkSession.clear
Change Description: This new method requires a string to describe the reason the clear method was called. It was added to aid in diagnosing performance issues.
Note: This is a non-public API.
com.splwg.base.support.FrameworkSession.flush
Change Description: This new method requires a string to describe the reason the clear method was called. It was added to aid in diagnosing performance issues.
Note: This is a non-public API.
com.splwg.base.domain.common.maintenanceObject. MaintenanceObjectInfomationAlgorithmSpot.setEntity
Change Description: This method was changed from setEntity(BusinessEntity<?> entity) to setEntity(BusinessEntity entity). The change was needed to support Java 6 (and may possibly have been a JDK 6 bug).
java.util.HashSet Behavior Change
Change Description: A behavior change in Java 6 exposed an issue that may require code changes. The iteration order of the HashSet changed. While HashSet does not guarantee any iteration order, there have been instances of code that relied on the old behavior.
In Hibernate, a given table/column can only participate in one property mapping. If a table/column is included in more than one property mapping (based on the defined constraints), the artifact generator must determine which property mapping to use. In prior versions of the artifact generator, based on Java version 5, if two constraints went to the same table and used some of the same fields, the preference order was determined based on the order that the constraints were returned from a database query. In OUAF 4.x, which is based on Java 6, that order comes out differently, resulting in a different property mapping that broke the product upgrade. This is a rare situation, but whenever it arises, the property mapping must come out the same as before the upgrade to avoid breaking the upgraded product.
A check was added to the artifact generator to always deterministically identify the property mapping. If the artifact generator cannot make a definitive decision, this results in the following error:
Constraints should differ in at least some way.
To address the error, the developer should decide which constraint should be followed and which should be "ignored".
Choose a field that is in the constraint to be ignored that is not in the other constraint, and add it to the annotation for the entity implementation class. For example,
* @BusinessEntity (cobolPersistence = true, tableName = CI_RC, ignoredFKFields =
{"STEP_RC_SEQ"},