I have recently been working on writing a custom service to automate some computed information retrieval from an RTC Server. That service I wanted it to have a configuration property that could be set/modified using the Advanced Properties page (https://<yourServerURI>/ccm/admin). In that process I faced a “dummy” issue that made me waste some precious time, so I wanted to share here my experience.
This post is meant to be a really short one, with the idea of providing a tip based on my experience.
Note: if this a kind of custom element you may need in your deployment but you don’t know where to start, I advice you to firstly take a look at Hello Jazz — How to write a simple Jazz component at jazz.net.
A LITTLE INTRODUCTION
Let’s begin by the component I declared to own my custom service, it is of some importance as we will see later:
I was feeling quite happy when noticing that the configuration property was appearing in the Advanced Properties section of the Admin Page, and saving a modification was causing an update in the teamserver.properties file. So far so good.
THE ISSUE AND ITS SOLUTION
But then my surprise came when after restarting the server (see the configuration property was declared with a FRAMEWORK_RESTART_REQUIRED policy); the value appearing in the Admin page was always the default one, and so the value my service was receiving at runtime. Why not picking the modified value while it was updated in teamserver.properties file?
I found the following (not so clarifying) warning in the logs:
Launch callback handler] WARN ository.common.transport.AbstractElementDescriptor - The com.ibm.ret.scm.build.history.service bundle's plugin.xml uses the component id "com.ibm.ret.scm.build.history" as the prefix to a <configurationProperty> element's "name" attribute with the value "com.ibm.ret.scm.build.history.service.buildquerypagesize"
Hmm, what if a collision was all the issue? So I updated the declaration as follows:
Et voilà! It began to work as expected. Updating the property at the Advanced Properties section not only did the value to get updated in the teamserver.properties file (this wasn’t really news); but it was persisted and picked up at restart, and my custom service taking advantage of it.
This consideration is also valid if you are coding a custom Async Task (as I described in this previous post), and you want to define a property for it.
I guess my dev colleagues at the repository team won’t face this dummy declaration problem, my naming convention was not really well though; but for me facing this problem and the solution was a little discovery, and sharing it here I hope it can help some others avoid this situation.