Common Problems

Overview

Herein is a collection of common issues you might encounter while developing for QM. Each entry should ideally describe the symptoms of the issue, explain any relevant backround on why this issue exists, and offer a solution or workaround.

Changes to an Advanced Server Property Do Not Take

Symptoms

You change the value of an advanced server property, then hit the save button, but QM does not seem to reflect your new preference. The save showed a green success message and the new value is showing in the Advanced Server Properties UI as expected. Refreshing the advanced server properties page returns the value of the preference back to its default.

Explanation

This is a bug in Foundation. The save actually failed, but was not reported as such. The change you made was never persisted, so when you refresh the page and the value is pulled from the repository, you'll see the value revert to its default.

Cause

There could be several ways to produce this behavior, but the one known cause as of this writing has to do with the "name" attribute of the property in your plugin.xml file.

<configurationProperty
	name="com.ibm.rqm.print.common.foo.bar.MyService.myProperty"
	displayableName="My Property"
	description="A test property to demonstrate this bug"
	type="BOOLEAN"
	default="true"
	required="true"
	accessPolicy="OPEN"
	updatePolicy="NO_RESTART_REQUIRED"/>

In the above example we see that the author choose to name their property using the fully qualified name of the service to which the property is attached. This is an entirely reasonable way to choose IDs for properties as it ensures uniqueness of the IDs.

The problem is that somewhere deep down in the Foundation code that reads these properties, the ID of the component that this service belongs to will be prepended to the property's ID. In this case that would result in a name like com.ibm.rqm.print.com.ibm.rqm.print.common.foo.bar.MyService.myProperty. For whatever reason, the Foundation code that handles advanced server properties cannot handle this form of ID. The same fails. To compound the problem, the failure is not handled properly and is reported by the UI as a successful save.

Solution

Do not begin your configuraitonProperty names with the component ID. In this case, you can solve the problem by using an ID like common.foo.bar.MyService.myProperty instead.

It looks like IDs only need to be unique across a component though, so it is probably sufficent to just use an ID like MyService.myProperty.