This document contains information on work completed as part of the Kuali Rice Version 2.0 Beta.
Released: 01-10-2012
Table of Contents
Note
For a list of changes between the different Kuali Rice 2.0 beta releases, see the Changelog section at the end of the release notes.
Welcome to the Kuali Rice version 2.0 Beta!
This is the first major release of the Kuali Rice software since version 1.0 which was released in August of 2009. This release brings many new and exciting features and improvements to the Kuali Rice middlware and application development platforms. This document provides early information on the work that has been done as part of 2.0 development and how one can get started working with the software during the beta test phase of the project.
The primary architectural goal for this release of Rice was to position the platform for cross-version service compatibility moving forward. With the increase in the number of applications (both internal and external to Kuali) that are integrating with the Kuali Rice middleware platform, the ability to provide for compatibility across different versions of Kuali Rice has risen to the forefront within the community as a critical need. The end result is intended to be a platform on which institutions can build applications without worrying about major forced upgrade paths for all integrated applications whenever they deploy a new release of Kuali Rice.
Another major effort that was undertaken in support of compatibility work was an effort to improve the modularity of the various components of Kuali Rice. In version 1.0.x of Rice, a high degree of coupling was present in numerous places. Work was done as part of this release to help improve upon that situation.
In addition to the architectural efforts supporting compatibility and modularity, Kuali Rice 2.0 sees the introduction of two new major modules.
The first of these is the Kuali Rapid Application Development (KRAD) module. KRAD is meant to provide the next generation of application development capabilities to those who are building applications based on Kuali software. KRAD provides a platform that can be utilized to build enterprise applications in a way that provides a more rich and flexible user experience than could be provided with the existing Kuali Nervous System (KNS). In fact, KRAD is intended to be the eventual replacement for the KNS which is the platform upon which much of the existing Kuali application software has been written. Note, however, that KNS is not being removed as of Rice 2.0. Work will continue on KRAD past the 2.0 release of Kuali Rice.
The final major piece of functionality that was undertaken for this release was the introduction of the Kuali Rule Management System (KRMS). KRMS is a business rule management system which can be used to author and maintain business rules that can be utilized during decision making processes within an application. This includes the ability to use business rules defined in KRMS to define rules for workflow routing, notification, validation, and other custom scenarios.
More details on each of the major efforts can be found in later sections of this document.
Highlights of this release include:
- Refactoring of all remotely accessible services to position them for cross-version compatibility with future versions of Kuali Rice. This includes a migration from Java serialization-based services to SOAP-based web services.
- Reduction in the number of places where a Kuali Rice client application will interact directly with the Kuali Rice standalone server database (when using integration models like embedded KEW).
- Improvements to the Kuali Service Bus to allow it to support requirements for version compatibility.
- Introduction of a new approach to server and client-side caching use the Spring caching abstraction coupled with Ehcache. This includes a new user interface for managing caches.
- Breakdown of the codebase into smaller modules to increase modularity and flexibility of the software.
- Numerous improvements to the design and documentation of Kuali Rice apis.
- Integration of an out-of-the-box LDAP connector for Kuali Identity Management.
- Introduction of the Kuali Rules Management System (KRMS) module for creation and execution of business rules.
- Introduction of the concept of PeopleFlows in Kuali Enterprise Workflow.
- Introduction of the Kuali Rapid Application Development (KRAD) module, the next revision of the KNS which includes rich UI features and is based on Spring MVC instead of Struts.
- Ability to configure Bitronix as a JTA alternative to JOTM and XAPool.
- Many of the Kuali Rice library dependencies have been updated.
Kuali Rice 2.0.0-b7-SNAPSHOT can be downloaded from the Rice website at http://kuali.org/rice/download/beta.
There are three different distributions of Rice available: source, binary and server. Please read the Installation Guide for more details on each of these distributions.
JavaDocs can be found at http://site.kuali.org/rice/2.0.0-b7-SNAPSHOT/apidocs/index.html
For the beta test, we have a wiki space to collect and maintain for beta testers.
Formal documentation for this release is under review. Other than KRMS and KRAD Chapters, the documentation found at http://site.kuali.org/rice/2.0.0-b7-SNAPSHOT/reference/html/portal.html has not yet been updated for Rice 2.0.
If you encounter any difficulty, please don't hesitate to contact the Rice team on
our public collaboration mailing list at <rice.collab@kuali.org>.
Please indicate that you are using the 2.0.0-b7-SNAPSHOT version of Rice.
As mentioned in the overview and highlights, there were many major changes that were made in support of the goals of the Rice 2.0 release. During the implementation of modularity and version compatibility changes, there were many structural improvements and refactoring changes to Rice that are intended to help set a stronger foundation for future releases. Additionally, the KRMS and KRAD modules brought a large amount of new functionality to the Kuali Rice platform. These next sections dive into these changes in more detail.
In Rice 2.0, we are providing what we call "middleware" or "service" compatibility. This type of compatibility is mainly concerned with compatibility between a client application and the version of the Kuali Rice standalone server with which it is integrated. The basic requirement here is that if the Kuali Rice standalone server (which hosts all of the Kuali Rice services) is upgraded to a new version, that should not force any applications that integrate with those services to also upgrade (unless the server has been upgraded to a new "major" version such as Rice 3.0, 4.0, etc.). It should be able to continue to interoperate with the new set of services without having to pull in new Kuali Rice client libraries or (in the case of manual web-service integration) it should not have to modify the way in which it invokes and handles remote service calls.
The image below shows what the target is for version compatibility from the perspective of major, minor, and patch releases of Kuali Rice.
The type of compatibility being implemented for version 2.0 is in contrast to what we call "framework" compatibility, or the ability to upgrade a client application to a new version of the Kuali Rice client libraries or development framework without having to make any forced changes to that client application. Those who use Java are familiar with this type of compatibility because that is the level of compatibility that is generally provided between releases of the JDK (this is sometimes called a "drop-in" replacement). Working toward a goal of framework compatibility is on the roadmap for the Kuali Rice project, however the Rice 2.0 release makes no guarantees that it will provide such a level of compatibility moving forward.
More info on this and also Framework Version Compatibility can be found in our Kuali Rice Version Compatibility Statement.
The following sub-sections will delve into some specific work that was done in support of version compatibility.
In Kuali Rice 1.0.x, services based on Java serialization were the primary services used for integration between Kuali Rice and client applications. The mechanism by which serialization was performed used Spring's HTTP invoker remoting framework. Java serialization is convenient for Java-to-Java application interaction. However, a SOAP web service approach allows for a greater level of interoperability between applications, including those not written in Java. Additionally, serialization can sometimes inherently cause compatibility issues when attempting to communicate between applications which might be running different versions of Java or different versions of libraries.
To this end, the services in Rice 2.0 have all been reimplemented as SOAP-based web services. There will be no Java-serialization based service distributed with Kuali Rice 2.0. However, the Kuali Service Bus will still support publishing of services that use Java. As part of this effort, the team has taken care to carefully design the message formats such that:
The "required" portions of the message format are well-defined
The proper format of data in the messages in well-defined
Error and exception cases are well-defined
The services are designed to allow for safe evolution over time
The services are namespaced and named appropriately
The services are versioned appropriately
There is consistency in how services are designed and documented
Much of the above information can be found in the WSDL's which are generated for each of the services. The WSDL defines the message formats, operations, and error conditions of the numerous Kuali Rice services. This effort of service refactoring is at the heart of what we are calling "version compatibility" for the Kuali Rice 2.0 release.
Note that while SOAP is being used as the primary way in which services are exposed in Rice 2.0, there will likely be work in the future to make services available using the REST architectural style.
In order to support requirements for version compatibility, there were numerous changes that needed to be made to the Kuali Service Bus. This ultimately resulted in a reworking of much of the internals of the KSB (with the exception of it's messaging functionality). The major changes made to the KSB for Kuali Rice 2.0 were:
Client applications now connect to the service registry through a SOAP web service, rather than through direct connections to the KRSB_SVC_DEF_T and related tables.
There is a new API for the ServiceBus which is well documented and acts as the client application interface point with the KSB.
The practice of storing a java serialized form of the service configuration in the database was altered to store an XML-serialized service descriptor. This allows for more portability and greater access for non-Java applications to interact with the service bus.
Removed the faulty "dead service" indicator from the registry.
Added the concept of a service status to the registry.
Added service version number information to the registry.
Replaced the concept of the "service namespace" with the concept of an "application id".
Introduced the concept of an "instance id" which identifies an instance of an application. This allows the KSB to better handle applications that are clustered with multiple deployments all publishing the same set of services.
Much more flexibility in how a client application can configure and use the KSB. For example, a client application could just configure the KSB client to act as a publisher of a service, or it could just connect to the KSB as a consumer of services. As well as additional configuration permutations related to support for reliable messaging and "development" mode (where services are not actually published).
A general refactoring of the internal architecture of the KSB related to handle it handles the publishing lifecycle of services as well as synchronization with the shared service registry.
As can be seen from the list above, much work was done to the service bus for Kuali Rice version 2.0. For more details, read the following page https://wiki.kuali.org/x/T3dyEg
In Rice 1.0.x, parameters, namespaces, and components were part of the KNS module of Rice. Client applications would access tables in the Kuali Rice server database directory in order to read and write values from these tables. As part of the general effort to modularize the Rice platform, it was decided that these three concepts were core concepts since they were used outside of the pure application development domain of the KNS (parameters in particular are used all over the Kuali Rice codebase). To this end they were moved to the newly established "core" module of Rice (see more information on modularity work in later sections).
Additionally, SOAP services were created for each of these to eliminate the need for a client application to directly communicate with the related database tables, instead using a service-oriented approach to interacting with these different information sources. This resulted in the creation of the following services:
org.kuali.rice.core.api.parameter.ParameterRepositoryService - remote service which provides operations related to system parameters
org.kuali.rice.core.api.namespace.NamespaceService - remote service which provides operations related to namespaces
org.kuali.rice.core.api.component.ComponentService - remote service which provides operations related to components, as well as implementing a new model for publication of "derived" components
For working with parameters, there is still a ParameterService this is provided as part of the client-side API. This service is configured with the application id of the application and delegates calls down to the remote ParameterRepositoryService.
For the ComponentService, it provides a new mechanism for publication of "derived" components, which can include components that are derived from an application's data dictionary configuration. This is a replacement for the "getNonDatabaseComponents" method which was part of the RiceApplicationConfigurationService in Rice 1.0.x. It uses a push model in contrast to the pull model which was used in Rice 1.0.x.
More information about these individual services and their available operations can be found in the javadocs. Also see the following page for more details on the work that was done with these services, including a description of the new model used for publication of derived components: https://wiki.kuali.org/x/tg5yEg
In Rice 1.0.x, the RiceApplicationConfigurationService was a service published by all KNS applications which provided callbacks into the application from the Kuali Rice standalone server. This service was removed in Rice 2.0 for various reasons. The reasons for it's removal and information on it's effective replacements can be found on the following page: https://wiki.kuali.org/x/vA6tEg
In Rice 1.0.x, may of the services (particularly the KIM services) had
general-purpose lookup methods which took a Map<String, String>.
In this map, the key was intended to represent the property name on the data
element being looked up and the value was intended to be the value to search
for. The value itself could contain various wild card characters and other
operators to allow for the construction of more complex searches. However, there
were a few inadequacies with this approach:
If an institution wanted to implement their own version of the service, they would effectively need to implement a complex interpreter which would take the incoming String value and determine how to implement the lookup according to the values passed in.
There was no way to preform cross-property "ors" with this model.
There was no support for "paging" of query results.
The contract itself tended to be weakly defined, resulting in service methods that would be hard to maintain from a service compatibility perspective.
To this end, some work was done to design a general purpose lookup API that could be applied in a standard fashion across the various Rice services which needed it. The following page describes more about the various possibilities for implementing this as well as the solution which was chosen: https://wiki.kuali.org/x/PR9yEg.
The implementation of this api can be found on the core-api module under the
package org.kuali.rice.core.api.criteria.
The Kuali Enterprise Workflow services have been refactored for version compatibility in a similar fashion to the rest of the services in Rice. As part of this effort, a bit of a rearchitecture of the service layer and APIs for workflow were performed as well. The major changes made to the workflow services and apis are as follows:
The
WorkflowDocumentclass is now an interface and is created usingWorkflowDocumentFactory.createDocumentorWorkflowDocumentFactory.loadDocumentinstead of creating new instances through theWorkflowDocumentconstructor.SimpleDocumentActionsWebServicewas combined withWorkflowDocumentActionsto create the newWorkflowDocumentActionsServiceremotable service.WorkflowInfoandWorkflowUtilitywas removed and replaced with the following services:WorkflowDocumentServiceActionListServiceDocumentTypeServiceNoteServiceRuleService
The various KEW framework services were refactored to conform to service version compatibility standards. This includes services for document search customization, action list customization, workflow notes, document security, rule validation, and workflow rule attributes.
The various KEW message queues were refactored to conform to service version compatibility standards. This includes queues for document routing, blanket approval, immediate email reminders, searchable attribute indexing, document requeuing, etc.
In the KNS, both
KualiWorkflowInfoandKualiWorkflowDocumentwere removed as it was deemed this duplicate level of abstraction was unnecessary. In the case ofKualiWorkflowDocument, existing references were changed to justWorkflowDocument. In the case ofKualiWorkflowInfo, code was changed to call one of the new KEW services that was added in Rice 2.0.
Some rough notes with more details on the work that was done in KEW can be found here: https://wiki.kuali.org/x/fwuREg
One of the major KEW framework refactorings that was undertaken for Rice 2.0 was a reimplementation of the various components that support Document Search customization. Full documentation on these changes and how to utilize them is still in progress, but a summary is as follows:
SearchableAttribute- class still named the same but moved to a different package, method names changed, returnsRemotableAttributeFieldinstead ofList<Row>Client applications no longer allowed to override or use these attributes:
DocumentSearchCriteriaProcessorAttributeDocumentSearchGeneratorAttributeDocumentSearchResultProcessorAttributeDocumentSearchXMLResultProcessorAttribute
The only valid document search-related attributes are now:
SearchableAttributeDocumentSearchCustomizerDocumentSecurityAttribute
The
DocumentSearchCustomizerreplaces most of the original document search-related attributes. It is a single attribute which allows for customization of criteria, results, and various other aspects of the Document Search operation.The customizer itself is not remoted, instead a
DocumentSearchCustomizationHandlerServiceis published by each KEW client application. This allows for a client application to implement as many customizers as they want and map them to the document types they should apply to viaDocumentTypeconfiguration. The Document Search functionality itself will then callback into the client application when it needs to via the publishedDocumentSearchCustomizationHandlerService.The new document search framework uses the
RemotableAttributeFieldabstraction for defining fields that should be displayed as extra search criteria. This is in contrast to Rice 1.0.x where KNSRowandFieldobjects were transmitted using Java serialization. This old model did not translate well to SOAP-based services and had numerous other problems as well (namely that not all ofFieldandRowwas properly serializable or could be interpreted correctly by the Rice standalone service, such as custom formatters, values finders, etc.).
Further documentation on how to migrate from the old document
search framework to the new document search framework is forthcoming. For the
time-being, the best resource is to look at the javadocs for the
org.kuali.rice.kew.framework.document.search package. All of
the framework apis should have fairly thorough javadocs. Additional, some rough
notes on the document search work and architectural service approach for the
customization handler service can be found near the bottom of this page: https://wiki.kuali.org/x/fwuREg
In Rice 1.0.x, caching was implemented using a framework called OSCache along with distributed caching flushing behavior across the KSB. This worked well in general, however this setup was plagued by issues of far too many cache-related message events getting generated and sent. Additionally, OSCache is a long-dead project which has not had any activity in a long time. In order to ensure that Kuali Rice was positioned for service compatibility moving forward, an effort was undertaken to revamp and update the caching architecture utilized by the Rice platform and find a better and more sustainable solution.
The result is a solution based on the caching abstraction provided with the core Spring framework version 3.1. The backend caching implementation being used is Ehcache (which is the default recommended by Spring). There is a also integration with the Kuali Service Bus for sending cache eviction messages out to interested listeners. This allows us to keep our caching consistent across different applications in an enterprise architecture which has been integrated with Kuali Rice.
More details on the specific work that was done to rearchitect the Kuali Rice caching infrastructure can be found here: https://wiki.kuali.org/x/XgmWEg
In version 1.0.x of Kuali Rice, the software was divided into 3 main modules: api, impl, and web. While this was convenient from the development perspective, it resulted in a high level of coupling between the various "logical" modules of Rice (the core, kew, kim, ksb, etc.). Attempts were made to rectify some of these issues in Kuali Rice 2.0. Since the full vision for modularity in Kuali Rice was not in scope for the 2.0 release, as much work was done on modularity as could be permitted in order help reach version compatibility goals for the release.
Primarily, this included the creation of numerous "api" and "framework" modules and the partitioning of Kuali Rice into various sub-project modules. This structure can be seen when looking at the source code for Rice 2.0. The overall vision for modularity in Kuali Rice as well as some notes on specific changes that were made in pursuit of it can be found at the following links:
A new concept was added to Kuali Enterprise Workflow as part of workflow routing requirements for Kuali Coeus. The requirement was essentially to replicate the functionality of "Maps" in the existing Coeus system upon which Kuali Coeus is based. These maps are simply lists of people or roles who can approve in a particular order. This order is defined by a series of "stops". At each stop there can be a number of possible approvers which may have delegates.
There was not really an equivalent concept in KEW today, this is essentially like a mini-workflow itself. So the concept of PeopleFlows were added along with a new activation type called "Priority-Parallel" activation. This priority-parallel activation allows for action requests to be activated at a node in parallel if they have the same priority, but in sequence if they have different priority values.
Further details on the implementation of PeopleFlows, their lineage in Coeus, as well as some screenshots of the maintenance user interface can be found here: https://wiki.kuali.org/x/3R6REg
The previous section introduced the concept of PeopleFlows. The KRMS module will have integration with PeopleFlows built in through the use of a custom type of "Action". This action will allow a rule author to build a business rule and then indicate that the action that should be executed if the rule succeeds would be to route to the specified PeopleFlow.
Details on the way this integration is implemented can be found here: https://wiki.kuali.org/x/3R6REg
KRAD (Kuali Rapid Application Development) is a framework that eases the development of enterprise web applications by providing reusable solutions and tooling that enable developers to build in a rapid and agile fashion. KRAD is a complete framework for web development that provides infrastructure in all major areas of an application (client, business, and data) and integrates with other modules of the Rice middleware project. KRAD is the next generation of the Rice Kuali Nervous System (KNS) and Kuali Student development frameworks. It expands on the ability to rapidly create user interfaces with XML while providing more flexibility with layouts and user experience. In addition, KRAD allows for the creation of modern, rich user interfaces using the jQuery and Fluid frameworks.
How does KRAD improve on the KNS? See Benefits of KRAD.
To learn more about KRAD, please visit the following pages:
In addition, see various analysis pages here (Note: some of the information might be incomplete or out of date): KRAD Analysis
KRMS (Kuali Rule Management System) is a new module in Rice that enables the externalization of pieces of business logic (rules) from an application such that it is customizable without need for additional client programming. Agendas containing custom business rules can be defined, edited and stored in the repository, and then executed by the application against some set of information (facts).
There is also integration between KRMS and KEW's new PeopleFlow concept that enables invocation of the rule execution engine from within a workflow. Rules can be configured with PeopleFlow actions that specify PeopleFlows to route to or to notify.
View the following analysis page for some additional information on KRMS:KRMS Analysis
For Rice 2.0, we now support:
Tomcat 6 (Servlet API 2.5, JSP 2.1)
Tomcat 7 (Servlet API 3.0, JSP 2.2)
With this change, we have dropped support for Tomcat 5.5 (Servlet API 2.4, JSP 2.0).
There were many changes made to the various direct and transitive dependencies for Kuali Rice. Additional documentation is forthcoming on what these specific changes were, but the following is a summary of some of the highlights:
Spring 3.1
Apache CXF 2.3.6
OJB 1.0.4-patch7
includes various patches from the Kuali community
Direct Web Remoting (DWR) 3.0.RC2
Ehcache 2.4.6
Groovy 1.8.1
joda-time 2.0
JOTM 2.1.9
Bitronix 2.1.1
Quartz 1.8.4
Spring Security 3.0.7
Struts 1.3.10
Tiles 2.2.2
jQuery 1.6.3
There were many other changes made in Kuali Rice 2.0 which are not included in the previous section. The following list is a highlight of some of these. For a comprehensive list of changes that were performed, the Jira issues are the best place to look.
Removal of DateUtils and NumberUtils
Changes in how unit tests and integration tests are run
Addition of Priority parallel activation type
Use of immutable objects and the builder pattern for various APIs
Removal of "object remoting" functionality from the KSB
Conversion of identifiers from numeric to character-based data types in KEW
Changes to PersistableBusinessObjectBase and notes
Normalization on a single concept of "application id"
Unique constraint on kim permission namespace:name and responsibility namespace:name
Clean up of multiple "key-value-pair" style classes
Transition from custom-written email services to standardizing on the spring mailer
Move to Maven version 3
DateTimeService converted to use configuration parameters instead of system parameters, allowing for it to be used through more of the system without the need for database dependencies
Kuali Communication Broker (KCB) integration turned off by default
Removal of IdentityManagementService, replaced with individual service calls in KIM
Replacement of AttributeSet in KIM service apis with simple Map<String, String>
Renaming of various data elements in KIM to more closely align with PESC standards
Ability for a RouteModule to be called back into multiple times in order to generate more requests in support of new PeopleFlow feature
Hours of availability awareness
Change from WorkflowFunctions to EDLFunctions (and package name changes) in eDocLites
Ability to define finer-grained Action List notification preferences for KEW
For the first beta release of Rice 2.0, the goal was to ensure that approximately 95% of the functionality was complete prior to the public beta test. The following sections summarize major work items that still need to be completed prior to the generally available release of Kuali Rice 2.0. Work will continue to try and resolve these issues as soon as possible for future beta releases.
There is still work outstanding on the caching infrastructure for Kuali Rice. Remaining work primarily revolves around how client-side caching is managed and performed. Much of this work relates to the outstanding issues resulting in the inability of configuring remote and embedded client-side integration patterns.
As a result of heaving refactoring of the document search frameworks for version compatibility in Rice 2.0, there is still work remaining before this framework will have parity with the implementation that was in place in Kuali Rice 1.0.x. Specific outstanding work that remains here includes:
Support for range-based searches on search attribute values
Proper data formatting in result set
Ability to indicate column visibility on searchable attribute fields
Ability to pass query parameters via the document search URL
The createproject.groovy script has not yet been converted over to produce a valid Rice 2.0-based project.
Document is still in a rudimentary state. During the course of the beta releases, it will be reviewed and augmented.
These guides and scripts are not yet fully complete. However, final documentation and scripts will be provided prior to the final release. To access rough versions of scripts and some contributed by other members of the community, please visit the beta test site.
The scripts to upgrade from a 1.0.3.3 version of Kuali Rice to version 2.0.0-b7-SNAPSHOT can be found in the following directory inside of the source distribution:
scripts/upgrades/1.0.3 to 2.0.0
Within this directory, are the following sub-directories:
db-updates - contains the SQL needed to upgrade from a Kuali Rice 1.0.3.3 standalone server service database to 2.0.0-b7-SNAPSHOT. Each of these scripts is dated and that indicates the order in which they should be run. SQL scripts for MySql are prefixed by "mysql". Scripts for oracle have no prefix on their name.
db-updates-client - contains the SQL needed to upgrade a Kuali Rice client application's Rice-related tables to 2.0.0-b7-SNAPSHOT. At this point in time, the only update required is to the KRNS_SESN_DOC_T table.
demo-data - this directory contains updates to the various pieces of Kuali Rice demo data. Chances are that most people performing an upgrade will not have demo data in their local database and will, therefore, not need to execute the scripts located within this directory.
support - this directory contains a groovy script which helps deal with the fact that unique constraints were added to the database for the combination of namespace code and name in both the KIM permission and responsibility tables
xml-ingest-updates - contains XML that needs to be ingested after the database upgrade is completed
There were nearly 800 Jira issues addressed in Rice 2.0. Below are links to Jira filters for the items addressed.
Highlights of the Beta 2 release include:
KEN and KCB services converted to standard SOAP services.
WorkflowAttributeValidationErrorreplaced by newAttributeErrorimplementation.Type IDs made optional on various pieces of the KRMS data model
KRAD sample application views moved to their own tab in the portal.
New DocumentType policy for ENROUTE error suppression
Added missing qualifiers to service model of delegate members in KIM
Additional documentation of KEW apis in the javadocs
Various improvements to the KRMS user interface functionality
Numerous bug fixes throughout the project
The full list of JIRA tickets that were resolved for Kuali Rice 2.0.0-b2 can be found here: http://links.kuali.org/kuali-rice-2.0.0-b2-jiras
Additional details on impacting changes in this release can be found here: https://wiki.kuali.org/x/EwO1Eg
Database changes for this beta release were minimal, see the mysql-2011-11-14.sql or 2011-11-14.sql scripts in the database updates directory inside the source code in order to perform a database upgrade from b1 to b2.
Highlights of the Beta 3 release include:
Some configuration work was completed, but full configuration for Rice standalone server not yet available. See impacting changes below.
RiceConfigurer refactored so that is doesn't depend on all the modules
KSB modularity improvements, see impacting changes below
CustomActionListAttribute converted to a remotable SOAP service
Bitronix upgraded to version 2.1.2
Application Document Status code for Doc Search re-enabled
KRAD fixes for iFrames in Internet Explorer, Chrome
Remotable fields can be added to a collection
'Copy rule' functionality implemented
Agenda Permission Authorization enhancements
Numerous bug fixes
The full list of JIRA tickets that were resolved for Kuali Rice 2.0.0-b3 can be found here: http://links.kuali.org/kuali-rice-2.0.0-b3-jiras
Created a new rice-ksb-server-impl module and moved ksb classes from rice-impl into there in preparation for remaining configuration work
Created a new rice-ksb-client-impl module and moved ksb classes from rice-ksb-server-impl to that module
Created a new rice-ksb-web module and moved web application related files into there
Moved org.kuali.rice.core.cxf.interceptors package from core-impl module to package org.kuali.rice.ksb.impl.cxf.interceptors in the ksb-client-impl module
Database changes in 2011-11-23.sql/mysql-2011-11-23.sql and 2011-11-28.sql/mysql-2011-11-28.sql scripts found in the database updates directory inside the source code in order to perform a database upgrade from b2 to b3.
Additional details on impacting changes in this release can be found here: https://wiki.kuali.org/x/EwO1Eg
Highlights of the Beta 4 release include:
Configuration changes made to more easily configure client applications with rice modules in LOCAL, EMBEDDED, or REMOTE modes
Spring Bean modularity improvement
Removal of many *ConfigSpringBeans.xml files
Easier configuration setup by simply specifying run mode of each module as configuration parameter
Default to remote run mode for many modules (KEW, KIM, KRMS, Core-Service, Location)
New Core-Service module
Upgrade Spring Framework to 3.1.RELEASE
Apache CXF upgraded to from 2.3.6 to 2.3.7
Numerous bug fixes
The full list of JIRA tickets that were resolved for Kuali Rice 2.0.0-b4 can be found here: http://links.kuali.org/kuali-rice-2.0.0-b4-jiras
Creation of WebModule concept - Created WebModule class and use that from ModuleConfigurer to load web modules as part of a special WebModuleLoaderListener class
StandardGenericXMLSearchableAttribute internal changes - refactored internally which resulted in a slight (and temporary) change to the internal class api.
Removed the use of the rice.ksb.loadModuleConfiguration configuration variable
Removed datasource.pool.size config variable
Removed Various *ConfigSpringBeans.xml files
Database changes in 2011-11-29.sql/mysql-2011-11-29.sql and 2011-12-07.sql/mysql-2011-12-07.sql scripts found in the database updates directory inside the source code in order to perform a database upgrade from b3 to b4.
Xml Ingestion changes 12-06-2011-ComponentMaintenanceDocument-doctype.xml found in the xml ingestion directory inside the source code provides a document type that previous database updates may have removed.
Additional details on impacting changes in this release can be found here: https://wiki.kuali.org/x/EwO1Eg
Highlights of the Beta 5 release:
Logout button issues have been fixed
Document search works with document types with searchable attribute
Ability to customize help link on document search
Application document status search support
Route Node Name and Route Node Logic search support
Customized Post Data-load Encryption
KRAD DocType updated to HTML 5
Many bug fixes
The full list of JIRA tickets that were resolved for Kuali Rice 2.0.0-b4 can be found here: http://links.kuali.org/kuali-rice-2.0.0-b5-jiras
KRAD bean and css refactor. In addition to the bean rename, there are significant changes to bean hierarchy, css names for ALL beans, and changes to how style sheets are being pulled into a view (we are now using a theme object). additionalCssFiles still is fine for adding additional css files (you no longer have to merge anything) and if you want to override or extend the theme in some way you can now do that easily as well.
You must use the new names for all KRAD work going forward as the old beans do not exist. Every file that contained old bean names has been updated if they were committed before today. A groovy script is included to rename any files using the old bean names in scripts/bean-rename-b4tob5. If you need to, easiest way to use this script is to place it in the directory containing your xml files along with it's beanReplacements.txt and run it.
LDAP module moved under KIM - What was the rice-ldap module is now under the rice-kim module. Its new artifact ID is rice-kim-ldap.
Final update of library dependencies, see KULRICE-4931 for details
Database changes to refactor KRMS context join table names - As part of this work,
three KRMS tables and the related indexes, constraints and sequences were renamed
a column name was changed
some data was updated
To apply this change, run the SQL DDL in scripts/upgrades/1.0.3 to 2.0.0/db-updates/2012-01-05.sql (for Oracle) or scripts/upgrades/1.0.3 to 2.0.0/db-updates/mysql-2012-01-05.sql (for MySQL).
Database change to add new DB index for improving action list performance. To apply this change, run the SQL in scripts/upgrades/1.0.3 to 2.0.0/db-updates/2012-01-06.sql (for Oracle) or scripts/upgrades/1.0.3 to 2.0.0/db-updates/mysql-2012-01-06.sql (for MySQL).