This page tracks major impacting changes post 2.0 release. Things such as database or package name changes for example. This page will serve as a holding pen for information on those changes.
Table of Contents:
KULRICE-6730 - Remove getBusinessRulesClass from MaintenanceDocumentDictionaryServiceImpl and TransactionalDocumentDictionaryServiceImpl
The following method has been removed from org.kuali.rice.kns.service.MaintenanceDocumentDictionaryService and org.kuali.rice.kns.service.impl.MaintenanceDocumentDictionaryServiceImpl
public Class<? extends BusinessRule> getBusinessRulesClass(MaintenanceDocument document);
The following method has been removed from org.kuali.rice.kns.service.TransactionalDocumentDictionaryService and org.kuali.rice.kns.service.impl.TransactionalDocumentDictionaryServiceImpl
public Class<? extends BusinessRule> getBusinessRulesClass(TransactionDocument document);
To apply this change, run the SQL in scripts/upgrades/2.0.0 to 2.1/db-updates/2012-02-27.sql (for Oracle) or scripts/upgrades/2.0.0 to 2.1/db-updates/mysql-2012-02-27.sql (for MySQL).
To apply this change, run the SQL in scripts/upgrades/2.0.0 to 2.1/db-updates/2012-03-05.sql (for Oracle) or scripts/upgrades/2.0.0 to 2.1/db-updates/mysql-2012-03-05.sql (for MySQL).
To apply this change, run the SQL in scripts/upgrades/2.0.0 to 2.1/db-updates/2012-03-13.sql (for Oracle) or scripts/upgrades/2.0.0 to 2.1/db-updates/mysql-2012-03-13.sql (for MySQL).
To apply this change, run the SQL in scripts/upgrades/2.0.0 to 2.1/db-updates/2012-04-04.sql (for Oracle) or scripts/upgrades/2.0.0 to 2.1/db-updates/mysql-2012-04-04.sql (for MySQL).
To apply this change, run the following SQL scripts for Oracle:
or the following SQL scripts for MySQL:
To apply this change, run the SQL in scripts/upgrades/2.0.0 to 2.1/db-updates/2012-04-16b.sql (for Oracle) or scripts/upgrades/2.0.0 to 2.1/db-updates/mysql-2012-04-16b.sql (for MySQL).
To apply this change, run the SQL in scripts/upgrades/2.0.0 to 2.1/db-updates/2012-04-16.sql (for Oracle) or scripts/upgrades/2.0.0 to 2.1/db-updates/mysql-2012-04-16.sql (for MySQL).
To apply this change, run the SQL in scripts/upgrades/2.0.0 to 2.1/db-updates/2012-04-25.sql (for Oracle) or scripts/upgrades/2.0.0 to 2.1/db-updates/mysql-2012-04-25.sql (for MySQL).
To apply this change, run the SQL in scripts/upgrades/2.0.0 to 2.1/db-updates/2012-05-11.sql (for Oracle) or scripts/upgrades/2.0.0 to 2.1/db-updates/mysql-2012-05-11.sql (for MySQL).
To apply this change, run the SQL in scripts/upgrades/2.0.0 to 2.1/db-updates/2012-05-17.sql (for Oracle) or scripts/upgrades/2.0.0 to 2.1/db-updates/mysql-2012-05-17.sql (for MySQL).
To apply this change, run the SQL in scripts/upgrades/2.0.0 to 2.1/db-updates/2012-05-21.sql (for Oracle) or scripts/upgrades/2.0.0 to 2.1/db-updates/mysql-2012-05-21.sql (for MySQL).
To apply this change, run the SQL in scripts/upgrades/2.0.0 to 2.1/db-updates/2012-05-24.sql (for Oracle) or scripts/upgrades/2.0.0 to 2.1/db-updates/mysql-2012-05-24.sql (for MySQL).
To apply this change, run the SQL in scripts/upgrades/2.0.0 to 2.1/db-updates/2012-05-25.sql (for Oracle) or scripts/upgrades/2.0.0 to 2.1/db-updates/mysql-2012-05-25.sql (for MySQL).
To apply this change, run the SQL in scripts/upgrades/2.1.0 to 2.1.2/db-updates/2012-09-26.sql (for Oracle) or scripts/upgrades/2.1.0 to 2.1.2/db-updates/mysql-2012-09-26.sql (for MySQL).
To apply this change, run the SQL in scripts/upgrades/2.1.0 to 2.1.2/db-updates/2012-10-12.sql (for Oracle) or scripts/upgrades/2.1.0 to 2.1.2/db-updates/mysql-2012-10-12.sql (for MySQL).
To apply this change, run the SQL in scripts/upgrades/2.1.0 to 2.1.2/db-updates/2012-10-17.sql (for Oracle) or scripts/upgrades/2.1.0 to 2.1.2/db-updates/mysql-2012-10-17.sql (for MySQL).
To apply this change, run the SQL in scripts/upgrades/2.1.0 to 2.1.2/db-updates/2012-10-19.sql (for Oracle) or scripts/upgrades/2.1.0 to 2.1.2/db-updates/mysql-2012-10-19.sql (for MySQL).
To apply this change, run the SQL in scripts/upgrades/2.1.0 to 2.1.2/db-updates/2012-10-24.sql (for Oracle) or scripts/upgrades/2.1.0 to 2.1.2/db-updates/mysql-2012-10-24.sql (for MySQL).
For client databases (MySQL only in this specific case), run the SQL in scripts/upgrades/2.1.0 to 2.1.2/db-updates-client/mysql-2012-10-24.sql
To apply this change, run the SQL in scripts/upgrades/2.1.0 to 2.1.2/db-updates/2012-10-25.sql (for Oracle) or scripts/upgrades/2.1.0 to 2.1.2/db-updates/mysql-2012-10-25.sql (for MySQL).
In some cases it may be desirable to only use the KNS without KRAD. For example if you're timelines push a conversion to KRAD out into the future, you may see some benefits with startup performance and with memory usage.
You can override the kradApplicationModuleConfiguration bean to not include any of the files in the UIF folder. That is, you only need to include these files:
<property name="dataDictionaryPackages"> <list> <value>classpath:org/kuali/rice/krad/bo/datadictionary/AdHocRoutePerson.xml</value> <value>classpath:org/kuali/rice/krad/bo/datadictionary/AdHocRouteWorkgroup.xml</value> <value>classpath:org/kuali/rice/krad/bo/datadictionary/Attachment.xml</value> <value>classpath:org/kuali/rice/krad/bo/datadictionary/AttributeReferenceDummy.xml</value> <value>classpath:org/kuali/rice/krad/bo/datadictionary/AttributeReferenceElements.xml</value> <value>classpath:org/kuali/rice/krad/bo/datadictionary/BusinessObjectAttributeEntry.xml</value> <value>classpath:org/kuali/rice/krad/bo/datadictionary/DataDictionaryBaseTypes.xml</value> <value>classpath:org/kuali/rice/krad/bo/datadictionary/DocumentHeader.xml</value> <value>classpath:org/kuali/rice/krad/bo/datadictionary/Note.xml</value> <value>classpath:org/kuali/rice/krad/bo/datadictionary/NoteType.xml</value> <value>classpath:org/kuali/rice/krad/bo/datadictionary/PessimisticLock.xml</value> </list> </property>
Likewise, this can be done for the ‘baselinePackages’ property on the dataDictionaryService bean.
The following changes impact KRAD UIF configuration (XML). Mostly these should be covered by the Bean/CSS conversion script documented below.
Previously the component title property was be used for various purposes. For example on Containers the title was used as a shorthand for setting header.headerText. The title property should be getting passed to the template and used to populate the title attribute on the corresponding tag (for example on a group this would be the div). Therefore the change was made to pass this through and add to the tags. The container property 'headerText' was added as a shorthand for setting the header.headerText property. The bean conversion script converts title to headerText. However it must be used with care since this should only be converted on containers (view and group), and not other components (like image or link).
Many component property names were changed to better reflect their purpose. The bean conversion script will take care of renaming the properties in XML configuration. For a full listing of changed property names, see the project file 'beanReplacements.txt'.
To provide more flexibility for adding header content, three groups were added to the Header component. These groups correspond to their render position relative to the h tag (header text). The first is named upperGroup and will render above the header text. The second is named rightGroup and will render to the right of the header text. The third is named lowerGroup and is rendered below the header text. One or more of these groups can have content for a single header.
The previous Header group named headerGroup has been replaced by the lowerGroup. The bean conversion script will convert any configuration on headerGroup to lowerGroup. If the content was intended to align to the right of the header text, this will need to be manually changed to rightGroup.
Previously all HTML content was rendered through a Field component. The field wrapped the content with a span and could also render a label. For some content types this did not make sense (for example iframe, label, and header). In addition, for others it might be useful to have a label, but general not needed (link, action, image). Therefore a component type named ContentElement was introduced. A content element corresponds directly with the HTML content tag without additional wrapping. For the first set of fields described above (iframe, label, header), a content element was created and the field was removed. For the second set content elements were created, but the field component remains.
Mostly the impact of this was taken care of by the base bean definitions. In some cases the actual bean id changed which is handled by the bean conversion script. In cases where the field support remains but there is now a content element, application XML should be reviewed for places where it makes sense to change to the content element.
An effort begin towards the end of the 2.0 cycle to rework the KRAD CSS code. This began with implementing a naming convention and standard for applying style classes to components. This work was completed in 2.2 M1 with the rework of the style sheets. This included rewriting styles to correspond with the new classes and removing any old code. Changed style names within the UIF XML can be converted using the CssRename.groovy script. Custom style sheets will need to be updated manually.
Validation message handling has changed significantly in 2.2 M1. The new architecture addresses many issues, primary among these being accessibility. The ErrorsField component has been dropped and replaced with the ValidationMessages component (with subclasses PageValidationMessages, GroupValidationMessages, and FieldValidationMessages). Many properties of ErrorsField are no longer available. These changes include:
Some property names have changed which is handled by the bean conversion script.
With the 2.2-m1 release are two scripts that will automatically convert changed bean names, property names, and CSS classes. These scripts are located in the Rice project within folder:
These are groovy scripts. To run a groovy script:
The first conversion script is named BeanRename.groovy and renames bean ids and property names. This will find all XML files in the directory from which the script is run, and all sub-directories. Therefore you should first copy BeanRename.groovy and the file beanReplacements.txt to the directory which contains your UIF XML files, then run from that directory.
Please note if you have XML files that contain KNS definitions (such as the LookupDefinition or MaintainbleDefinition), this conversion script should not be run on those files.
The second script is named CssRename.groovy and renames CSS classes. This will find all CSS files in the directory from which the script is run, and all sub-directories. Therefore you should first copy CssRename.groovy and the file cssReplacements.txt to the directory which contains your CSS file, then run from that directory.
The help URL on the document and lookup level has been removed from the KEW document type. This means the "Help Definition URL" and the "Document Search Help URL" on the "Document Type" are depreciated and don't serve any function anymore. Instead the help URL are defined on the UIF-View level either within the data dictionary or the system parameters.
In 2.0, the Inquiry and DirectInquiry were separate widgets with separate properties on InputField. Therefore, when both were required both had to be configured with similar properties. This caused duplicate configuration. In 2.2, the DirectInquiry widget has been removed and the Inquiry widget supports rendering the direct inquiry when the field is not read-only. The direct inquiry behavior can be disabled with the Inquiry property enableDirectInquiry.
Any configuration referencing fieldDirectInquiry will need to be converted to the property named inquiry. Note if the standard inquiry and direct inquiry were both configured for a field, the direct inquiry can simply be dropped. If you were disabling the direct inquiry by fieldDirectInquiry.render="false", this can be changed to inquiry.enableDirectInquiry. The bean conversion script makes this change.
The process for adding growl messages server side has been modified. In 2.0, a growl was shown for each message in the GlobalVariables.getMessageMap() that was of type Info. The MessageMap has been enhanced to support a new growl type. For adding growls you now should call one of the following methods:
public void addGrowlMessage(String growlTitle, String messageKey); public void addGrowlMessage(String growlTitle, String messageKey, String... messageParameters); public void addGrowlMessage(String growlTitle, String growlTheme, String messageKey); public void addGrowlMessage(String growlTitle, String growlTheme, String messageKey, String... messageParameters);
No changes were made for adding growls client side (still call the method showGrowl(message, title, theme))
In Rice 2.0, a controller method needed to be built based on whether it would be called as part of a component refresh, or a full request. This was confusing as it required knowledge of the different refresh return method and prevented the method from being used for both types of calls. In 2.2, the controller methods no longer need to make this distinction. They can simply return the standard getUifModelAndView call for both component refresh and full requests.
Any controller methods that were returning updateComponent(uiTestForm, result, request, response) should be replace the return call with getUIFModelAndView(form).
The default layout for the action field group rendered by a table layout manager was changed from vertical box to horizontal box. This means for table with multiple line actions, the actions will now render in a horizontal row instead of vertical. If it is desired to have the actions align vertically, the actionFieldPrototype can be overridden.
The jQuery library in KRAD was upgraded from 1.6.3 to 1.7.2. Mostly this should not have an impact on applications. There were a couple of removed methods that might impact custom script. These and other notes can be found in the jQuery release notes:
In Rice 2.0 the Uif-FormView bean contained a footer defined that included the save, close, and cancel actions. The Uif-FormView bean has been changed to not include any footer actions by default. For these common actions, a bean named 'Uif-FormFooter' was created that can be used for a view or page when needed.
handleIncidentReport() in krad.message was changed so that it no longer replaces the view with the incident report. It checks if the content is incident report view and then returns true else it returns false. The view is now replaced by the updateViewHandler() in krad.ajax.
ajaxSubmitForm(methodToCall, successCallback, additionalData, elementToBlock, errorCallback) has been changed to ajaxSubmitForm(methodToCall, successCallback, additionalData, elementToBlock , preSubmitCall). This in turn calls the ajaxSubmitFormFullOpts(methodToCall, successCallback, additionalData, elementToBlock, errorCallback, validate,preSubmitCall, returnType).
The following new methods have been added to krad.ajax.js
1. actionInvokeHandler(component) - Instead of calling the jQuery('#kualiForm').submit(), it has been replaced by the actionInvokeHandler(component). Component is the element on which the action has been invoked. This method checks based on the data-attributes whether it is an ajax submit or a non ajax one and then calls one of the submit methods.
2. ajaxSubmitForm() - This in turn calls the ajaxSubmitFormFullOpts() with the validate flag set to false.
3. validateAndAjaxSubmitForm() - This in turn calls the ajaxSubmitFormFullOpts() with the validate flag set to true.
4. ajaxSubmitFormFullOpts() - Submits the form through an ajax submit, the response is the new page html runs all hidden scripts passed back (this is to get around a bug with premature script evaluation). It is similar to the old ajaxSubmitForm() but has some additional parameter which allow for providing hooks for successCallback,errorCallback and preSubmitCalls. It also takes a validate flag as well as a returnType. A returnType is used to request data from the server but the server may override it. If the validate flag is set it validates the form and proceeds if the form is valid. If a presubmit call is specified then it executes that and proceeds if it returns true. If the returnType is not given then it defaults to "update-page" and sets it on the data which will be submitted to the server. It then calls the invokeAjaxReturnHandler() to determine which handler function to call. The successCallback and errorCallback are handled as they were before in ajaxSubmitForm(). The elementToBlock and the lightBox processing remain the same.
5. submitForm() - This is used for non-ajax calls. This in turn calls the submitFormFullOpts() with the validate flag set to false.
6. validateAndSubmitForm() - This is used for non-ajax calls. This in turn calls the submitFormFullOpts() with the validate flag set to true.
7. submitFormFullOpts() - Does a non ajax submit. The data-attributes that are passed in as additional data are written as hidden params to the form before it is submitted.
8. invokeAjaxReturnHandler() - This method iterates over divs in the content that is passed in to determine which handler functions to call. The handler functions are initialized in krad.initialize.js
9. updatePageHandler() - Called if the returnType is "update-page". Finds the page content in the returned content and updates the page, then processes breadcrumbs and hidden scripts. While processing, the page contents are hidden (works similar to the the updatePageCallback()).
10. updateViewHandler() - Replaces the view with the given content and runs the hidden scripts. Called when the returnType is "update-view".
11. redirectHandler() - Called when the returnType is "redirect". Replaces the contents of the window with those of the redirected URL.
12. updateComponentHandler() - Called when the returnType is "update-component". Retrieves the component with the matching id from the server and replaces a matching _refreshWrapper marker span with the same id with the result. In addition, if the result contains a label and a displayWith marker span has a matching id, that span will be replaced with the label content and removed from the component. This allows for label and component content seperation on fields (Works the same as updateRefreshableComponentCallback)
Please see these classes for the changes made here. Some method signatures were changed for this support and some methods were removed for clarity.
Previously to clear (or reset) form properties between requests the postBind form method could be implemented. This method has been removed in M2. Now to indicate a property should not be persisted in session (thus reset for each request) the annotation @SessionTransient should be added before the property declaration.
To help with performance, some nested beans that were being initialized in the XML were pulled out. In the code, if determined the component is needed, a call is made to then initialize the bean.
This means for these removed beans, if you were using the nested notation to set a property (for example, 'nested.property'), this will now throw an exception. You must first initialize the nested bean, then set the property. Note in cases where the default initialization was removed, a top level bean was created making it easy to initialize if needed.
The following nested beans were removed:
<bean parent="Uif-VerticalBoxSection"> <property name="header.upperGroup.items"> <list> ... </list> </property> </bean> change to <bean parent="Uif-VerticalBoxSection"> <property name="header.upperGroup"> <bean parent="Uif-HeaderUpperGroup"> <property name="items"> <list> ... </list> </property> </bean> </property> </bean>
For performance reasons the KRAD JSP templates were converted to use the FreeMarker templating language. Any custom components (or template overrides) that were created will need to be converted to FreeMarker.
See this page for a comparison of JSP and FreeMarker: https://wiki.kuali.org/display/KULRICE/Freemarker+and+JSP+comparison
Templates are associated with a component (bean) using two properties now. The first is the template property which gives the location of the template source. The second is the templateName property which is the name of the template to invoke (in FreeMarker this is the macro name). If you override one of the default templates, make sure to also give the template a unique templateName.
For security reasons the escapeHtmlInPropertyValue property on DataField was defaulted to true. Therefore if you have a property which has HTML that should be rendered, you will need to set this property to false on the data field.
Loading the view object from bean definitions can take up to 4 or 5 seconds in some cases (although this is improving with the removal of default nested beans). To boast performance, an enhancement was put in to 'pre-load' the view objects. This means when the application starts up, it will fetch one or more view objects for a particular view and hold until a request is made. The number of views to preload is configured by the view property preloadPoolSize. This is set to 1 by default for all views except lookups and inquiries.
<bean id="CourseView" parent="Uif-FormView"> ... <property name="preloadPoolSize" value="3"/> </bean>
The views are loaded in a separate thread so the startup time is not impacted. Whenever a request for a view is made, a view from the pool is returned and a new view object is pulled in a separate thread to replace it. If no view objects exist in the pool at the time of a request, a call is made to build the view object. For high load views you can experiment with increasing the pool size so that a view is always available (Note a log statement is made when a view is not available from the pool, thus this can be used to help tune the parameter).
Note though storing the preloaded view objects consumes memory. In Rice (with Sampleapp) the storage was 91mb (and Rice does not have many views compared to what other applications like the KFS would).
In previous versions of Rice a user can keep requested view objects whose forms get added to the user session (note this is only for views that have session persistence enabled). Although there are clear points implemented, they do not catch many exit actions. Therefore more and more memory continues to be consumed, even though the user might be long done with the form.
To prevent this problem a configuration parameter was introduced that limits the number of forms per user session. The parameter name is maxNumberOfSessionForms and is set to 5 by default. This parameter can be tuned as needed however it is not recommended to go lower than 5 (think of nested lookups that might take place from a view).
In your rice config XML: <param name="maxNumberOfSessionForms">10</param>
Whenever the number of session forms is greater than the configured maximum allowed, a form will be removed from the session. For determining which form to remove in these situations, the forms are arranged according to when they were accessed. In other words, the form whose last requested action time is oldest will be removed (most recently accessed forms will be kept).
Note: The "Add Message to Route Log" permission assignment to the KR-SYS "Technical Administrator" role was present in the main 126.96.36.199 dataset but missing in the bootstrap dataset for 2.0.0. The sql script removes the permission from the role to make upgraded databases consistent with new ones.
To apply this change, run the SQL in scripts/upgrades/2.1 to 2.2/db-updates/2012-07-20.sql (for Oracle) or scripts/upgrades/2.1 to 2.2/db-updates/mysql-2012-07-20.sql (for MySQL).
A new message table and locale system parameter was added to support external messages.
To apply this change, run the SQL in scripts/upgrades/2.1 to 2.2/db-updates/2012-08-29.sql and 2012.09-13.sql (for oracle) or scripts/upgrades/2.1 to 2.2/db-updates/mysql-2012-08-29.sql and mysql-2012-09-13.sql (for MySQL).
To support guest access a new KIM user with id 'guest' was created along with a guest role.
To apply this change, run the SQL in scripts/upgrades/2.1 to 2.2/db-updates/2012-09-29.sql (for oracle) or scripts/upgrades/2.1 to 2.2/db-updates/mysql-2012-09-29.sql (for MySQL).
AjaxAction and its bean Uif-AjaxActionButton was removed. All bean references should change to use 'Uif-PrimaryActionButton' (ajax is the default now). The bean update script can be run to apply this change.
Property validatedLineActions on CollectionGroup was removed. Now actions that are defined in lineActions can have the property 'performClientSideValidation' flag set to true to indicate the line should be validated.
Removed MessageMap#public void addGrowlMessage(String growlTitle, String messageKey)
Removed MessageMap#public void addGrowlMessage(String growlTitle, String growlTheme, String messageKey)
Removed MessageMap#public void addGrowlMessage(String growlTitle, String growlTheme, String messageKey, String... messageParameters)
Use MessageMap#addGrowl(GrowlMessage growl)
Property labelKey of BaseConstraint (and therefore all constraints) was renamed to messageKey. The bean update script can be run to apply this change.
Property baselinePackages of DataDictionaryService was renamed to additionalDictionaryFiles. In addition changed from a List<String> to Map<String, List<String>> where the map key is the namespace the dictionary beans should be associated with.
New tables and sequences were added to the KRMS schema to support Type-Type Relations, Natural Language Translation, Reference Object Bindings features (Rice 2.x - KRMS for KS Analysis).
To apply this change, run the SQL in scripts/upgrades/2.1 to 2.2/db-updates/2012-11-14.sql (for Oracle) or scripts/upgrades/2.1 to 2.2/db-updates/mysql-2012-11-14.sql (for MySQL).
Renamed MaintenanceForm to MaintenanceDocumentForm
Renamed MaintenanceView to MaintenanceDocumentView