Home > Release Notes

4.7.6

Release Date: November 26, 2009

Backward compatibility

Warning messages are now raised on nodes defining the osd:class property without osd:access property.

Important : on the next release, nodes defining only the osd:class property will be considered as terminal nodes . 

For more information, see JavaBeans .

Obsolete API

The following classes have been removed from the API, but are still available for backward compatibility:

• com.onwbp.core.service.AbstractConfigurationFacade

• com.onwbp.core.service.ModuleServices

• com.onwbp.core.service.ServiceInstaller

• com.onwbp.core.service.SpecificSetupFacade

Archives

It is now possible to define a mode when importing an archive.

Permissions

Hidden rows in a table can no longer be selected in the tableRef drop-down box in another table.

Validation

Uniqueness constraint has been improved for optimizing the global validation process on adaptations. On some cases, it has been observed that validation process duration is reduced by several orders of magnitude. See bug #2202.

The internal incremental validation framework has been enhanced to reduce the duration of successive validation processes. On some cases, it has been observed that revalidation duration is divided by four.

Workflow

New category for log

A log category named workflow has been added. Thanks to this new category, workflow logs are now isolated.

Before this evolution, workflow logs were done in the kernel category. They have been moved to this new category workflow (they have not been duplicated).

This is why it is necessary to update the ebx.properties file to ensure compatibility (or else workflow logs will be lost): a line must be added for the new category.

For extra information, see ebx.properties documentation .

New mail variables

New mail variables are available:

• workflow.workItem.label : to indicate the label of the current work item.

• workflow.workItem.description : to indicate the description of the current work item.

Publication service has changed

The publication service has been improved in order to publish many processes at once.

For extra information, see publication documentation .

Data Model API

AdaptationTable.getSchemaNode() is ambiguous.

• AdaptationTable.getSchemaNode() has been deprecated and replaced by AdaptationTable.getTableOccurrenceRootNode() .

• A new method AdaptationTable.getTableNode() is available.

For extra information see AdaptationTable

Bug Fixes

Core Cache

• [2119] Failure when recording into history.

  Some records' updates and inserts are not logged into history, if the server is serving many concurrent requests.

• [2124] XPath notation '//' not supported by SchemaNode class

  A ClassCastException occurs when the method SchemaNode.getNode(aPath) is called with a path beginning with '//'.

• [2127] Temporary files remain in History directory.

  On an attempt to create an invalid table record, EBX.Platform does not successfully write the error into history. Then, some text files remain in the repository history folder (they are named like '5D62B910-BD83-11DE-821B-00D48FF565D1.txt').

Documentation

• [2131] Properties and logs are not formatted as expected in EBX.Platform documentation.

  As an example, in the 'Performance Guidelines' section, performance memory cache for insufficient memory is not formatted as expected: carriage returns are missing.

Import Export

• [253] Behaviour of ProcedureContext.doImportArchive

  If the method ProcedureContext.doImportArchive is invoked, and the archive to be imported defines a change set but this change set is empty (no changes), then the import is done in 'replace' mode instead of 'change set' mode (see javadoc).

• [2111] Import error if schema has changed.

  The import throws an exception when the change-set declares a modification on a field that does not exist in the schema of the target. For example, it happens if a column has been renamed.

• [2149] In a newly installed environment, the XML or CSV export fails.

  In a newly installed environment (the application server has not been restarted since the first installation), if the end user requests an XML or CSV export from the Manager, the operation fails (FileNotFoundException for generating the temporary file on the server).

• [2154] A call to import or to export CSV or XML service via HttpManagerComponent raises an error.

  It reports a PreconditionFailure : "Schema node [xxxx] must be a table node".

• [2160] Node values containing "linefeed" and CSV Import/Export not properly handled.

  It is possible to feed a String value with linefeed characters (osd:text, xs:string with maxLength > 999, UIBeanEditor with textarea, ...).

  Those characters are not properly handled in CSV Import/Export.

UI

• [1577] The 'super-owner' user can create an adaptation in a read-only branch.

  If a user has "super-owner" privileges, he can create an adaptation instance even in a home with read-only permissions. This is inconsistent with the documentation.

• [1803] EBX.Manager 'expand node details' policy has no effect on table record display.

  It is possible to configure EBX.Manager node display policy in its adaptation configuration ('Ergonomic & behaviour policy' section). However, the 'expand node details' parameter is not taken into account in the table record form.

• [2118] Table record selection link from a UIServices generates an 'access denied' since release 4.7.4.

  The table record selection generated by ServiceContext.getURLForSelection() is no longer recognized by EBX.Manager as a valid process event; as a consequence, it logs a 'User event rejected' and reports an 'access denied' to the user.

• [2120] "Detail" links not available in some comparison screens

  If a "home" comparison service is launched in a sub-session of EBX.Manager, "detail" links to data are not generated.

• [2123] Cancel button is useless in table record creation mode

  The buttons 'close' and 'cancel' are redundant, and 'cancel' button has an unexpected behaviour.

• [2141] The severity "Fatal" is not correctly reported in table record form.

  Validation items with severity "Fatal" are reported as warnings in table record form.

• [2161] Sizing problem with small window in workflow execution section.

  In workflow execution section, the work list selector (to the left) and work space (to the right) are not sized properly in small window: work list is displayed above the work space.

• [2162] Archive import not in "replace mode" as requested

  Importing an archive with change set in the Manager is not in "replace mode" even if the checkbox "include change set" is unchecked.

• [2172] The calendar component does not set the date when "today" is clicked.

  The "Today" button positions the calendar onto the current month; it should also select the current date and close the calendar.

• [2186] The display in table view is erroneous after an OperationException is thrown in a TableTrigger

  When the method TableTrigger.handleAfterModify() throws an OperationException , the values displayed in the table view are erroneous: the displayed values are the modified ones, even though the modification has been rejected because of the OperationException thrown.

Users & Permissions

• [1831] Mass delete service is available on table even if the table node is set as read-only in permissions.

  Mass delete service is available on table even if the table node is set as read-only in permissions.

• [2140] Handling of record 'hidden' permission by foreign keys.

  EBX.Manager proposes a link to a record referred by a foreign key ( osd:tableRef ), even if the user has no permission to see the referred record. If the user clicks on the navigation link to the record, EBX.manager properly returns an "access denied" page.

• [2143] Branch visibility for owner or super owner.

  When a super-owner puts a "hidden" permission on his branch, then this branch disappears from the home view.

Validation

• [2098] A node that is inside an aggregated list is not correctly handled by the direct validation.

  If a node is the descendant of an aggregated list node, its direct validation will throw an undocumented exception.

• [2173] Explicit dependency declaration has too large an impact for incremental validation.

  The developer can declare an explicit dependency for a constraint by means of the method ConstraintContext.addDependencyToInsertDeleteAndModify(aTableOccurrenceNode) . However, in the context of incremental validation, the constraint is indeed re-checked even if the value of another node in the same table is modified (the source of the dependency being unchanged).

• [2175] The 'xs:unique' constraint is re-checked if any node has been updated in the table.

  This is a consequence of bug #02173.

• [2190] A node that is inside an aggregated list is not correctly handled by the incremental (re)validation

  If a node is the descendant of an aggregated list node, its (re)validation will create fatal validation errors. The erroneous validation message is: "The value defined is a list but cardinality constraint 'maxOccurs' is 1".

• [2191] Validation status is not displayed as expected for 'fatal' validation errors.

  Fatal validation errors are not counted in Adaptation header (validation status).

  Those fatal validation errors on node are not displayed in 'red' color on top of the table record form. Fatal validation errors are not mentioned as 'fatal' in Adaptation validation report page of EBX.Manager.

• [2202] Identity-constraint 'xs:unique' has too large a validation cost.

  The explicit validation of the identity-constraint 'xs:unique' is done on a per record basis, which implies too high a CPU cost for large tables. It should be done via a set-level algorithm instead.

Home > Release Notes