Back Home
  Release Notes For BugRat 2.5

Release 2.5 of BugRat is an interim release. A number of BugRat users were struggling with servlet API 2.2, which made substantial changes to how a servlet is referenced in URLs. Specifically, the API added the concept of "context", and unfortunately redefined getServletPath() such that is did not return the context. Thus, all servlets coded to the previous API, and using getServletPath() (used extensively by BugRat), were broken. Because I had made a mess of the URL production by littering the code with different snippets of code from varying stages of development, fixing the problem was not a simple patch, as many quickly discovered, so I decided a more complete fix was needed.

Also prompting release 2.5 is the fact that many developers have been attempting to put BugRat onto databases other than MySQL. In theory, there should be no need to code for SQL differences, but in practice it is almost unavoidable. For instance, Oracle does not allow the name "comment" to be used as table or field names.

Which brings up a very important point about this release...

SEVERAL SCHEMA NAMES HAVE BEEN CHANGED

Because Oracle has reserved names that BugRat used in its schema, we were forced to modify these names to support Oracle, or forever force Oracle users to patch every release. Because most modern databases, including MySQL, provide simple commands to change table and column names, I decided that now was the time to make the change.

If you are a current BugRat installation, and you wish to upgrade to version 2.5, then you must make the following changes to your existing database before you begin running the new version of BugRat. Furthermore, once you have made these changes, you will not be able to use the database with the older versions of BugRat without changing the names back to their original names.

The following are the name changes required by BugRat 2.5.

That is all. Once you have renamed these tables and fields, your database will be ready to use by the release 2.5.

If you seriously can not rename these tables and fields (say you have built other code around the database and can't afford to change it), then your only choice is to patch DescriptionJDBC.java, BugRatAction.java, and EmailContentJDBC.java to use the old names. I hope to make these names constants in a future release, which will greatly simplify a change such as this one.

Design Changes

I note here, for those who might be hacking on BugRat, changes made to the code design.

JDBC Handler and Parameters Changed

Ok, I admit it. My understanding of JDBC URL's was not complete, and my approach of specifying the parts of the URL and then constructing the URL from those parts was simply not right. Thus, this has been changed.

In the previous version, you specified several Initial Parameters to the servlet so that it could initialize the JDBC driver and connection. You no longer specify the JDBC_Host, JDBC_Port, et.al. properties. These have been replaced by two primary parameters - jdbcUrl, and jdbcDriverClassName. Furthermore, for extensibility, and to support peculiar JDBC drivers, you can also specify jdbcProp_N parameters, which will then be added to the Properties passed to the DriverManager to connect.

Please see the WEB-INF/web.xml configuration file for comments that details all of these JDBC parameters.

Object IDs Are No Longer Autoincremented!

Autoincrement is a nice feature. But it is not portable. For this reason, object ids are now created by BugRat without using autoincrement. Instead, BugRat uses a table named "sequence" with a row for each table that requires new unique ids. BugRat simply retrieves the id (nextseq) from the table to use for the object's ID, then increments id in the table for the next request.

What does this mean to you? If you are running an old version of BugRat that still uses autoincrement, then you need to fill in this sequence table so you do not start trying to overwrite existing objects in the database. To help you, I have added two new functions to the Admin servlet. The first lets you view the current ID values, and the other will "adjust" the IDs. The adjustment consists of determining the current maximum ID in each table, and then setting the IDs in the sequence table to values greater than the max IDs. You can use this command any time that you believe the sequence table is out of sync with your actual object IDs.

These new commands are on the admin page. They are the last two items under the Miscellaneous list.

DBConfig Made A Singleton

One of the problems with the three servlet design of BugRat was that when the admin servlet made changes to properties, the other servlets did not see these changes. The servlets reloaded the config whenever they made a property change. However, there was no communication between them, so the other servlets did not reload.

The new code makes DBConfig a Singleton. This eliminates the three copies that were constructed by the three servlets. This also eliminates the redundant memory consumption. Further, I added a listener mechanism that notifies all of the servlets whenever the DBConfig is modified.

MailQueueThread Made A Singleton

The previous release created a MailQueueThread for each servlet. This was simple, but wasteful. It also posed problems when one considered more complex used of the mail queue. Thus, to accomodate future needs, the thread was made a singleton that all of the servlets share.

Removed Debugging

All of the debugging left in the previous release has been removed or placed inside debug blocks.


Back Home Adjust the sequence ids used for new object IDs.