Fork me on GitHub

n. Slang a rough lawless young Kuali developer.
[perhaps variant of Houlihan, Irish surname]
kualiganism n

Blog of an rSmart Java Developer. Full of code examples, solutions, best practices, et al.

Tuesday, August 28, 2012

Tomcat JSP trimSpaces Optimization Improvement


There was a thread awhile back on Remove blank spaces from HTML generated from Kuali JSP's. Basically, Bin had an issue where some KFS documents were so huge, that it was leading to performance problems. There was some discussion on several solutions. I wanted to point out one really easy one that eliminates the redundant whitespace in all JSP files with just 4 lines in your tomcat web.xml file.


Wherever your tomcat installation is, it probably looks something like this:
(02:26:25) [3] ls -ldh /Library/Tomcat/Home/*
-rw-r--r--@   1 leo  staff    55K Mar 31 07:45 /Library/Tomcat/Home/LICENSE
-rw-r--r--@   1 leo  staff   1.2K Mar 31 07:45 /Library/Tomcat/Home/NOTICE
-rw-r--r--@   1 leo  staff   8.6K Mar 31 07:45 /Library/Tomcat/Home/RELEASE-NOTES
-rw-r--r--@   1 leo  staff    10K Mar 31 07:45 /Library/Tomcat/Home/RUNNING.txt
drwxr-xr-x@  26 leo  staff   884B Jun 12 05:41 /Library/Tomcat/Home/bin
drwxr-xr-x@  10 leo  staff   340B Aug  6 03:29 /Library/Tomcat/Home/conf
drwxr-xr-x@  21 leo  staff   714B Mar 31 07:44 /Library/Tomcat/Home/lib
drwxr-xr-x@ 173 leo  staff   5.7K Aug 23 09:02 /Library/Tomcat/Home/logs
drwxr-xr-x@   3 leo  staff   102B Mar 31 07:44 /Library/Tomcat/Home/temp
drwxr-xr-x@   9 leo  staff   306B Aug 23 13:25 /Library/Tomcat/Home/webapps
drwxr-xr-x@   3 leo  staff   102B Jun 12 05:53 /Library/Tomcat/Home/work

In $CATALINA_HOME/conf/web.xml replace:


After doing this, you need to clean out the $CATALINA_HOME/work path. If you don't, nothing will change.


Monday, August 27, 2012

Automating Workflow XML Ingestion


Workflow objects are stored persistently in your RDBMS. These are complex objects with complex rules. There's just no practical way to update your RDBMS to make changes to your Workflow configuration directly. At this time, the best way to update your workflow configuration is via the XML Ingester. It's an excellent tool because of all the great debugging feedback it gives; however, it lacks automation capabilities. If we want to deploy remotely via Jenkins or something else, it's a little unhandy.

This post is to explain how to easily setup your Kuali application to automatically deploy workflow changes on environment startup. The real hero here is the builtin xml polling in Rice.


This is the change process that is followed for delivering a workflow configuration change to an environment.

1 Job for Polling Changes on trunk

In Jenkins, you can create a job specifically intended to poll for changes. What we want to do is poll for changes to our workflow path. If we are storing workflow changes in somemodule/src/main/resources/myinstitution/rice/somemodule/document/workflow/, we can set our jenkins job to poll for changes here.

2 Copy Updates

You then want to copy the modified workflow files to a location where they are packaged into a zip artifact.

3 Deploy zip Artifact

Now that we have the packaged changes, the only thing left is to push them out to the specified environment.

Here's a visual:

Here's a overview of the release flow for getting your changes out with a release:


As I mentioned before, the work is all done by Rice with the org.kuali.rice.kew.batch.XmlPollerServiceImpl. All you need to do to get it to work is setup the following in your rice-config.xml or the configuration file of whatever application you're using (kc-config.xml for example).

For versions of rice prior to 2.3.x use:
<param name="kew.xml.pipeline.lifecycle.enabled">true</param>
instead of
<param name="xml.pipeline.lifecycle.enabled">true</param>


These are the scripts I used which I described above


Now you should be able to setup some automation so you environment can automagically deploy workflow xml that is changed with each commit/release.

Tuesday, August 14, 2012

KFS Archetype and kualigan-maven-plugins Restructuring Update

kualigan-maven-plugins-1.1.0 Released

You may remember kfs-archetype 1.0.5 and kfs-maven-plugin 1.0.8, but I have since merged these under the monicker kualigan-maven-plugins. This convention was originally established by ASF where plugins and plugin apis gather under a parent project. That is pretty much what I have done here at Github. The biggest reason I have done this is to pull in some other development and make it more accessible from a single place as well as create a structure for more plugins and archetypes (you didn't think I was going to stop with just kfs, did you?) For those looking for kfs-archetype and kfs-maven-plugin, they are still there. I have updated the documentation to clarify supported features and usages while also excluding features for future development.


One of the biggest features with this release is having JRebel support builtin. Previously, if you wanted hot-code replacement, you had to use the Hotspot approach or Jetty (pretty much the hotspot approach). If you wanted to use Tomcat, you definitely needed to use hotspot. Not only that, but hotspot requires you to start your JVM in jpda mode. For those unfamiliar, this is debug mode. With debug mode, you get some really great features.
  • It's slow
  • You can't change methods or classes.
  • It's slow.
JRebel is great. Here's a feature comparison with hotspot.

Setting up JRebel

I should really start with getting it. Once you've downloaded it, you need to setup your license. This is easy. Kuali Developers get a 1 year license (renewed annually) because Kuali is OSS. Simply apply for the license at

Setting up the license is easy. You can do this via your IDE. If you do not use a supported IDE (I use emacs), then you need to use an alternate approach. JRebel ships with a configuration wizard. You can run it like this:

Once you have you license setup, you need to configure your maven environment variables to use JRebel:

I put my JRebel in $HOME/jrebel

Once you have everything setup, you just execute the following from the maven overlay:

Until now, the recommended method was to use a run goal instead of run-war because running an unassembled war was the best way to track changes made to classes for hotspot modifications. Since we're not using hotspot modifications, we do not need to rely on the run goal. We can run a fully assembled war without having to shutdown the app server. Now, whenever a class is compiled, JRebel will pick up the change and make the necessary updates. No need to run jpda. Works with tomcat 7! That means, if you want to run tomcat like it were jetty, you now can.

Here's what it looks like:

What If I Already Have an Overlay?

With my overlays and those created from the kfs-archetype, I followed the convention set by the Rice project. That is, it is a multi-module maven webapp project. That implies there's a module where classes reside and there's a separate web module for constructing the war. I simply add the following to the war/pom.xml.

Notice that the jetty scanInterval is set to 0. This is setup this way so that jetty will not use the hotspot loading.

What's Next?

You probably already gathered this from looking at the github project, but here it is anyways:
  • kc-archetype for KC overlay projects
  • kc-maven-plugin to help run KC maven overlay projects
  • thinclient-archetype for making rice thin clients.
  • kuali-maven-plugin for generic kuali task project tools
  • Ruby on rails-ish database migrate functionality
  • Maven archetypes for liquibase custom refactorings.
  • Rice standalone overlay archetype