KOLE 1.5.x Installation Guide
The latest stable patch release of KOLE is 1.5.8 version released on February 5th, 2015. The table below highlights some of the differences in the 1.5.0 and the consecutive patch versions.
Version | SVN Location | Notes |
---|---|---|
1.5.0 | https://svn.kuali.org/repos/ole/tags/ole-1.5.0/ | This was the first 1.5.0 stable tag, but wasn't deemed to be "Go live" version by Chicago/Lehigh |
1.5.1 | https://svn.kuali.org/repos/ole/tags/ole-1.5.1/ | This is a "Go Live" version for Lehigh with solr 3.6 |
1.5.2 | https://svn.kuali.org/repos/ole/tags/ole-1.5.2/ | This is a "Go Live" version for Chicago with Solr 4.9. The major difference was in the performance of solr on a huge data volume. |
1.5.2.1 | https://svn.kuali.org/repos/ole/tags/ole-1.5.2.1/ | This is an intermediate critical-patch fix on 1.5.2 which was critical for Chicago. |
1.5.3 | https://svn.kuali.org/repos/ole/tags/ole-1.5.3/ | This is be the final "GO LIVE" version for Chicago university. |
1.5.3.1 | https://svn.kuali.org/repos/ole/tags/ole-1.5.3.1/ | Intermediate patch release before 1.5.4 to fix some critical performance issues regarding 1. Editing a big with large number of items 2. Generation of overdue notices. |
1.5.4 | https://svn.kuali.org/repos/ole/tags/ole-1.5.4/ | Â |
1.5.5 | https://svn.kuali.org/repos/ole/tags/ole-1.5.5/ | Â |
1.5.6 | https://svn.kuali.org/repos/ole/tags/ole-1.5.6/ | Â |
1.5.6.1 | https://svn.kuali.org/repos/ole/tags/ole-1.5.6.1 | Â |
1.5.6.2 | https://svn.kuali.org/repos/ole/tags/ole-1.5.6.2/ | Critical patch to provide Indexing by range. This was to avoid doing a full index when only partial records were corrupted. |
1.5.7 | https://svn.kuali.org/repos/ole/tags/ole-1.5.7/ | Â |
1.5.8 | https://svn.kuali.org/repos/ole/tags/ole-1.5.8/ | Performance fix: Problem with rendering the batch process job details page (OLE-7360) Performance fix: Additional POs or Additional charges to Invoices takes too long (OLE-7328) |
Â
The guide below will describe in as much detail as possible the process of building one of the 1.5 tags  and database migration processes for in between versions.Â
- Pre-requisites:
- Hardware: Kuali OLE can be built on both windows and linux platforms. The hardware specs will differ from institution to institution, but the default cloud settings where the codebase is deployed on a regular basis is as follows;
- Amazon EC2 instance (type m1.medium)
- AMD 64 bit
- Dual core
- 7.5 GB RAM
- 840 GB HDD
- Amazon EC2 instance (type m1.medium)
- Software:
- Building the application
- Maven 3
- Java 7
- svn client
- Running the application
- Apache tomcat 6 or 7
- MySQL 5.5 or greater
or Oracle 11g
Configure Tomcat and MySQL/Oracle
To correctly configure Tomcat and MySQL/Oracle follow the section "Required Software" in the Developer Installation Guide.
- Building the application
- Hardware: Kuali OLE can be built on both windows and linux platforms. The hardware specs will differ from institution to institution, but the default cloud settings where the codebase is deployed on a regular basis is as follows;
- Checking out the deployable units: Depending on how you intend to run KOLE you can do the following;
- Install defaults and deploy the war(s): This is recommended for those who simply want to get the application up and running with the default and demo data.
- Checkout the olefs.war from:http://shrub.appspot.com/maven.kuali.org/release/org/kuali/ole/olefs-webapp/${version.number}/olefs-webapp-${version.number}.war (Rename it olefs.war before deploying)
- Checkout the oledocstore.war from:http://shrub.appspot.com/maven.kuali.org/release/org/kuali/ole/ole-docstore-webapp//${version.number}/ole-docstore-webapp-${version.number}.war (Rename oledocstore.war before deploying)
- Skip to step #5
- Customize the build: This is ideal for implementors or others who want to start with a base OLE (without demo datasets) and then add their data.
- Checkout the codebase from https://svn.kuali.org/repos/ole/tags/${tag.number}; Here tag.number is the stable release version number .
- Build it using the following maven command from the root directory of the project location i.e OLE_DEVELOPMENT_WORKSPACE_ROOT
- The above command will output two war files under
- ${project.root.location}/ole-app/olefs/target/olefs.war
- ${project.root.location}/ole-docstore/ole-docstore-webapp/target/oledocstore.war
- Install defaults and deploy the war(s): This is recommended for those who simply want to get the application up and running with the default and demo data.
- Loading bootstrap only for sandbox purposes
Script for building the bootstrap sql
#!/bin/bash cd ${OLE_DEVELOPMENT_WORKSPACE_ROOT} mvn clean install -DskipTests=true cd ${OLE_DEVELOPMENT_WORKSPACE_ROOT}/ole-app/ole-db/ole-impex mvn clean install -Psql -Dimpex.scm.phase=none cd ${OLE_DEVELOPMENT_WORKSPACE_ROOT}/ole-app/ole-db/ole-liquibase/ole-liquibase-changeset mvn clean install -Pbootstrap-sql-only,mysql -Dimpex.scm.phase=none
You can skip to step 5.
- Loading local data (institution specific): This applies only if you are doing step 2.b.ii
- If you want to load your own values for the various reference tables, you will need to first populate them as per the documentation at Impex, Bootstrap, Demo and Local Data (points #7, #8, #9 b or #9 c). Once the data has been made available in .csv files under the appropriate folder, run the following maven commands to output the sql that we will later use to load the database with. The process automatically takes care of generating the right sql for MySQL and Oracle
- This will generate sql for the data files that you have which the ole build process can later use while setting up the database.
To load the institution specific data after the above executions, execute the following command:
Ensure there is a default user in the system. You could create using the sql file in JIRA-7246. Further need to update the web.xml under olefs and replace the defaultUser from ole-quickstart to the newly created user. (If you used ole-quickstart, then there is no need to update the web.xml)
- If you want to load your own values for the various reference tables, you will need to first populate them as per the documentation at Impex, Bootstrap, Demo and Local Data (points #7, #8, #9 b or #9 c). Once the data has been made available in .csv files under the appropriate folder, run the following maven commands to output the sql that we will later use to load the database with. The process automatically takes care of generating the right sql for MySQL and Oracle
- Customizing default parameters
- If you are running on a local server where access via localhost is sufficient for local testing and you use the defaults for database username and password, then there is no need to customize the defaults.
- For those who want to make the application available to the external public or use their own database username and password will need to override few defaults. Detailed information is available at Externalizable Parameters and pay attention to the entries in ${user.home}/kuali/main/local/common-config.xml. An example is provided here (DEV environment)
- Deploying to the server:
- If this is the first time starting installing the application or you would like to reload the OLE database after a change (typically if you ran the bootstrap or demo or institution profiles to generate new SQL), then follow the steps before deploying and starting tomcat.
- Create a file called
runonce.properties
under ${user.home}/kuali/main/local/olefs-webapp Contents of the file are as below:
project.db.reset=TRUE
What this enables is, during the application startup, a spring component will read the value of the project.db.reset and if its "TRUE" then starts the db initialization process automatically. It will automatically be updated to "COMPLETED" when db reset is done.
- Create a file called
- Once you have the final deployable artifacts olefs.war and oledocstore.war; you can place it in your app server and restart.
- If this is the first time starting installing the application or you would like to reload the OLE database after a change (typically if you ran the bootstrap or demo or institution profiles to generate new SQL), then follow the steps before deploying and starting tomcat.
- Testing the application
- To access the web apps, http://[host]/olefs and http://[host]/oledocstore should bring the apps up; Ofcourse this is assuming you have two deployables in one single instance. If you haven't customized any parameters then the url will be http://localhost:8080/olefs and http://localhost:8080/oledocstore (assuming tomcat is on 8080)
- Type "admin" in the login box; No password required.
- Upgrades: When upgrading if there are any database changes, they can easily be applied after the above steps have completed.Â
- Upgrade sql: Depending on which version you are working on, the location is ${SVN.LOCATION}/ole-app/ole-db/ole-sql/ole-liquibase-upgrade-sql/src/main/resources/org/kuali/ole/sql/mysql/
- There is mysql and oracle folders with the respective sql.
You can take the sql and manually apply it on your database.
Remember
The sql will have some "DATABASECHANGELOG" statements which you can ignore and execute the rest.
Setting OLE Up Behind a Reverse Proxy
Apache versions prior to Apache 2.4.4 cannot forward PATCH requests via the AJP protocol, which can interfere with some of OLE's APIs.
Â
If you are experiencing HTTP 501 ("Method Not Implemented") errors, this may be the cause. Check your Apache version and error logs for messages such as "ajp_marshal_into_msgb - No such method PATCH".
Possible fixes:
1. Use mod_proxy_http instead of mod_proxy_http in your proxy setup.
2. Use at least Apache 2.4.4 with mod_proxy_ajp
3. (Unverified) Use mod_jk instead of mod_proxy_ajp
Configuration for handling Incident Report Email Notification
The Incident Report screen allows an User Input field where system users can add information and submit. This is delivered to a pre-configured email address for further analysis. The following are the parameters that are to be added to make this functional.
The 'From' address on the notification email would be the email address from the contact information of the system user posting the Incident report.
The parameters are added to olefs-config-defaults.xml file.
<param name="mail.transport.protocol" override="false"></param> <!-- The mail protocol, usually smtp --> <param name="ole.fs.mail.server"></param> <!-- The mail server --> <param name="ole.fs.email"></param> <!-- The 'To' address for notifications --> <param name="ole.fs.exception.email"></param> <!-- The 'To' address for exceptions --> <param name="mail.debug">false</param> <param name="mail.smtp.host">${ole.fs.mail.server}</param> <!-- The mail server --> <param name="mail.smtp.port"></param> <param name="mail.smtp.ssl.enable"></param> <param name="mail.smtp.auth"></param> <param name="mail.smtp.username"></param> <param name="mail.smtp.password"></param> <param name="mail.relay.server">${ole.fs.mail.server}</param> <param name="mail.smtp.host">${ole.fs.mail.server}</param> <param name="kcb.smtp.host">${ole.fs.mail.server}</param> <param name="mailing.list.batch">${ole.fs.email}</param> <param name="kr.incident.mailing.list">${ole.fs.exception.email}</param> <param name="nonproduction.notification.mailing.list">${ole.fs.email}</param> <param name="KualiExceptionIncidentServiceImpl.REPORT_MAIL_LIST">${ole.fs.exception.email}</param>
The Incident Report Email Notification currently works only in Kuali Nervous System (KNS) screens and not in the newer Kuali Rapid Application Development (KRAD) screens. This is probably due to a Rice bug which would likely be fixed in Rice v2.4.
Â
Â
Operated as a Community Resource by the Open Library Foundation