Technical Design

A Compendium of Technical Issues from the development leading up through version 2.1.

Sakai Integration

SAMigo Integration

Presentation

--CSS Issues
--URL Filtering_AuthN
--Context Switching

Facades

JSF Component Development

Messaging
Paging and Sorting Components
Application Menu

JSF Design Notes
User data in the Grade Log display

The Grade Log history display includes human-readable information about the user who changed the grade. This is the first time we've needed to refer to user data for anyone who isn't currently playing a student role. We're currently just storing the User UID available through Authn. Either we can keep doing that and refer to a User Directory service at runtime to fill in the Grade Log display, or we can store the display data in our history along with the UID. The former allows for changes to accessibility of the user data and uses less DB storage. The latter keeps the data meaningful even after the user is no longer in the User Directory and could take much less time.

For right now, we'll take the "retrieve at display time" approach, but we should keep a close watch on this one.

Test Suite and Spring Refactoring

The configuration of the Sakai 2.0 gradebook placed constraints on what kinds of testing could be run during a build. Specifically, any tests that wrote records to the database could not be run as part of the build process, since we often want to rebuild without affecting the state of the database. We considered technologies such as dbUnit to manage the state of the database for testing, but decided that an optimal solution would include only the technologies currently in use: spring, junit, maven, and hsqldb.

In order to keep the database state unchanged and allow all of our tests to run every time we build, I made two signifigant changed to the project. The first change involved using the spring-mock extension, which provides base test classes for testing spring-based applications. These provide both access to an application context (we chose to disable the auto-wiring feature built in to these base classes) and the ability to run each test inside its own transaction, which by default rolls back when the method completes. This theoretically allows us to run any code we wish during testing, no matter how the code impacts the state of the database.

While refactoring the tests, however, I ran into a problem with hibernate-managed cascading collections. I don't know exactly how (or more precisely when during a transaction) hibernate stores cascaded child objects in the database, but it was not storing them quickly enough for our tests to run without errors. So, the second change I made was to use an in-memory hsql database for testing. This way, we can safely write records to a transient database without affecting the actual database that we may be using to test the UI. When the build process finished running all of the test, the database shuts down and the inserted records that we could not roll back due to the hibernate collections bug are destroyed. Specifying a system property of "mem=false" causes the tests to use the configured database rather than the in-memory database. This is useful for testing on databases other than hsqldb, but should not be needed frequently.

In order to switch database configurations on the fly, I split the datasource bean into its own spring configuration file. The tests check the "mem" system property, and use either db.xml or db-mem.xml in setting up the application context for the tests. I also split the hibernate-specific bean configuration into its own file, and added a global declarative transaction configuration so we could remove all of the redundant transaction proxies. The hibernate beans are configured in hib.xml.

When I followed the same strategy for the sakai-embedded spring configuration files, I noticed that every transaction that the gradebook attempted would roll back. By recombining the config files, and replacing the global transaction interceptor with individual transaction proxies for each bean (basically just keeping the configuration as it was), I was able to get the embedded gradebook to run properly. At some point, we should revisit this issue so we can keep the standalone and embedded spring configuration files aligned.