Custom Services Configuration Properties – naming collision issues

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:

componentDeclarationThen, in the service plugin, I declared the configuration property that I wanted to expose:

confProperty0Which details were at that time as follows:

confProperty1See the property ID was

 com.ibm.ret.scm.build.history.service.buildquerypagesize

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:

confProperty3

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.

Advertisements

One thought on “Custom Services Configuration Properties – naming collision issues

  1. Pingback: Due Date Notifier – an Asynchronous Task Example | rsjazz

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s