This problem has been seen on Tomcat 3.2 (and earlier)
when a SAX XML parser can't be found in the classpath.
To solve this problem install the file xerces.jar
as described in the installation guide.
Alternatively, replace jaxp.jar (v1.0) and parser.jar in
TOMCAT_HOME/lib with jaxp.jar (v1.1) and crimson.jar,
which can be obtained from the jdom distribution.
Ozibug expects to be deployed in an expanded mode,
however some servlet engines do not expand deployed
war files by default and must be configured manually.
An example is given in the WebLogic section of the
Ozibug 1.0.3 needs the following changes and permissions
to work correctly under the Tomcat security manager.
The context parameter
in the file OZIBUG_HOME/WEB-INF/web.xml
file must be set to the absolute filename of the
ozibug.properties file (Note:
this is not necessary in later versions of Ozibug.)
An example is included below.
This problem has been seen when the Ozibug servlet
context name contains restricted URI
characters, as described in
In particular, the problem was caused when the Ozibug
distribution was downloaded by Microsoft Internet
Explorer which by default saved the file as
ozibug.x.x.x.zip, this in turn was unzipped
When navigating to the Ozibug URL different browsers
handle the context name in different ways. Some
browsers (Mozilla, Netscape 7) always URL encode the
context name (eg., to ozibug-1%5B1%5D.4.0),
while others (Internet Explorer, Netscape 4.7, Opera)
only encode the name if the URL is not fully qualified
(eg., if only
has been specified). Browsers always seem to store the
Ozibug session cookie using the unencoded context name,
which may or may not match the the Ozibug URL. If a
match does not occur, then the Ozibug session cookie is
not sent back to the Ozibug servlet and hence it appears
as though there is no active session, causing the login
page to be redisplayed.
There is no apparent way to control this behaviour which
can in fact be further complicated by different
behaviour of the servlet container that Ozibug is
running under. So the solution is to simply use a
context name that contains no restricted characters.
By default each server instance the Sun ONE AppServer 7
starts has the security manager configured and turned on.
You must edit the file server.policy for
the server instance to give Ozibug the following permissions.
This file is located in the
config directory of the server instance
(the example shows the default location when
installed on a win32 platform.)
Read, write and delete access must be
granted for the servlet context directory.
Connect access is necessary for the smtp
notifications to be sent.
The following example shows the section of the
server.policy file necessary for Ozibug.
This section should be placed at the end of the file.
This example assumes that Ozibug has been installed in
Another option is to disable the security manager
for the whole server instance. This can be done
by commenting out the following line from the
config/server.xml file located under the
server instance directory.
This problem has been seen when using JDK1.2 with a
non-jndi aware servlet container (eg., Tomcat 3.x, Jetty)
when the JNDI class libraries can't be found in the
classpath. You'll need to download jndi.jar and
install it in the OZIBUG_HOME/WEB-INF/lib
directory, this J2SE optional package is available from
An Ozibug locale is defined by a set of three
property files which are located in the
The files messages_XX.properties,
define the resources for the locale
The locale is either specified by the client
browser in the request or by the Ozibug application
(configured by the default.language
and default.country properties
in the .../ozibug/WEB-INF/ozibug.properties file.)
The files messages.properties, audit.properties
and exceptions.properties define the resources to
use when NO locale is specified.
The property files can be zipped up into a jar
file and then the jar can be put in the
.../ozibug/WEB-INF/lib directory. This is optional.
To add a locale to Ozibug you simply need to place
the new property files in the .../ozibug/WEB-INF/classes
directory (you will also need to restart Ozibug.)
The locale will be used when specified in a request
by a client browser.
Change the default.language
and default.country properties
in the .../ozibug/WEB-INF/ozibug.properties file to
change the application locale.
When operating in a single locale the reference data
is specified in the file .../ozibug/WEB-INF/reference.xml
file. This data can be changed (or localized) through
the reference data screens by a system administrator.
When operating in a multi locale mode you may require
reference data to be localized for users in different
locales. This can be done by updating properties
specified in the I18N section at the
end of the messages.properties file.
Note that when you define these properties
they override the reference data
definitions that can be seen by the administrator.
Some servlet containers (notably Orion 1.5.2 and
WebLogic 6.0sp2) do not correctly translate multi-byte
characters when running on a Windows platform
(specifically when the system property
Cp1252). Ozibug 1.3.0 and later ships
with the necessary configuration to handle the known
cases, the details of which are outlined below.
Orion 1.5.2. The distribution includes a Orion
specific configuration file
../ozibug/WEB-INF/orion-web.xml that sets the
default character set to UTF-8. On
deployment the contents of this file is merged with
(in a standard Orion installation).
WebLogic 6.0sp2. The distribution includes a WebLogic
specific entry in the configuration file
../ozibug/WEB-INF/web.xml to treat all
incoming data as UTF-8. Refer to
WebLogic 6.0 Documentation
for further information.
WebLogic 6.1. The distribution includes a WebLogic
specific configuration file
../ozibug/WEB-INF/weblogic.xml that treats
all incoming data as UTF-8. Refer to
WebLogic 6.1 Documentation
for further information.
When constructing an Ozibug URL request such as that
used for running a report, special care is needed if
non-ascii characters (eg., accented characters or
multi-byte characters such as Japanese) are to form
part of the URL.
Most browsers allow pasting of such characters into the
location bar and will perform the necessary character
conversion to generate a valid URL. However, the
conversion performed is dependent on the character and
the browser. Most browsers convert single byte
characters (eg., ä) into a single byte Unicode
character representation (technically an invalid
conversion), whereas multi-byte characters are converted
into UTF-8 (Opera being a notable exception converting
to UTF-8 in both cases).
Servlet containers that operate with a single character
set of UTF-8 (either through configuration as above, or
design) cannot handle the single byte Unicode character
representations and generally ignore these
unknown characters and those following it. The
containers that have been seen to fall into this
category are Orion 2.0.2, WebLogic 6.0, Jetty 4.0.2 and
WebSphere 4.0.1. The solution is to manually translate
these characters into UTF-8, for example ä would
be represented by %C3%A4.
More information on the subject can found on the
This problem has been seen on Netscape 4 for Linux as
the default font size for the UTF-8 character set is
set to a massive 18. To change select the
Edit/Preferences/Appearance/Fonts menu and
then for the encoding, select Unicode, then
set the variable width font to 14.0 and the
fixed width font 12.0. Then select OK.
This problem can be seen when the browser caches the
stylesheet (which defines what colours to use.) This
can be overcome by refreshing the page in the browser
which forces it to retrieve a new (updated) stylesheet.
To track the time that you've spent on bug fixing
on a customer basis you can do the following.
Login to Ozibug as an administrator and create
a new custom field of type fixed list.
This is done by selecting the -- NEW --
option of the Select reference category
pull down list.
Enter the category as "Customer" and
the type as "fixed list".
Tick the modules that you wish these fields to apply to.
Now add the values of the list, which will be
each customer names, eg. "Customer 1",
"Customer 2", etc.
You may want to add an "Internal"
or "None" value for those bugs not
entered by a customer.
Create another custom field of type
This will be used to add in the time spent
on each bug.
Enter the category as
"Correction time (minutes)",
the type as free format and
tick the checkboxes of the modules that you
wish this field to apply to (the same as above.)
Logout as the administrator. The new fields
will now be shown when creating, editing or
displaying bugs in the modules that you
assigned them to.
Now comes the hard work - you must edit each
bug and assign the correct values to each field
for the customer and the time spent to correct it.
Now you are ready to generate a report based
on including the time and customer field and
sorted on the customer.
Select the report screen from the icon at the
top of the page, then from this page select
the required module from the Module
pull down list, located in the top left
corner underneath the page header.
Now select the fields you require in the report
by ticking the associated checkbox fields at
the left side of the table, this must include
the Correction time
Select the Customer field to sort on
by ticking its checkbox on the right hand side
of its entry on the screen.
At the bottom of the reports screen select
the type of the report to be
(comma separated values.)
You can now generate the report by pressing
the Apply button.
Your browser will prompt you to save the data
to a local file. Do this and then import the
file into your favourite spreadsheet application.
You can now use your spreadsheet functions
to sum the
fields for each customer and produce a total.
You can also use your spreadsheet functions
to post process the data, such as correcting
any malformed data items, or perhaps resorting
the rows and columns.
Will send notifications to email@example.com for
all new critical bugs in the module "Ozi Bug",
notice the conversion of the space character to
an underscore character.
One or more properties of the following format
can be specified to send email notifications
automatically when a bug is updated, note that
you will get a notification for each change to a
bug with the specified combination of module,
status and priority.
# Where x is the module name (can be * for all modules)
# y is the bug status (can be * for all status)
# z is the bug priority (can be * for all priorities)
The XML links or buttons cause Ozibug to output
an RSS report encoded in XML in a new browser
window. The browser may not be able to display
the page properly but its the URL contained in
the address bar of the page that is important.
The URL can be cut and pasted into your RSS
aware application, which will then read the
report and display it for you ...
For more information on this subject see the