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.
- TABLE 'comment' renamed to 'ratcomment'.
ALTER TABLE comment RENAME ratcomment
- TABLE 'action' renamed to 'rataction'.
ALTER TABLE action RENAME rataction
- FIELD 'comment' in TABLE 'action' renamed to 'actcmt'.
ALTER TABLE rataction CHANGE comment actcmt varchar(255) null
- FIELD 'size' in TABLE 'emailcontent' renamed to 'contsize'.
ALTER TABLE emailcontent CHANGE size contsize int
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