[KIEKER-1046] Feature request: Changing the configuration of the MonitoringController at runtime

[rju]

JIRA Issue: KIEKER-1046 Feature request: Changing the configuration of the MonitoringController at runtime Original Reporter: Andre van Hoorn

---

Raised by Sönke on the [April, 19 Kieker meeting|meeting-20120419].

• His preferred solution would be to reload the properties file at runtime.
• Another solution, suggested by ourselves, was the use of the JMX interface.

As a first step, we should analyze, for which configuration properties this makes sense.

[rju]

author Sönke Reimer -- Mon, 11 Jun 2012 16:18:24 +0200

Another requirement belonging to this one is a triggered initialization (e.g. the following additional methods on class MonitoringController)

//bm begin
private static IMonitoringController cvInitializedMonitoringController = null;

public static final void initialize() {
  cvInitializedMonitoringController = LazyHolder.INSTANCE;
}

public static final boolean isInitialized() {
  return getInstance() != null;
}    
//bm end

public static final IMonitoringController getInstance() {
//bm begin
  return cvInitializedMonitoringController;
//bm end
}

In our case the monitoring.properties to be used for kieker will be extracted from ear-archive or db after the first instrumentation probe has already been run.
So we need an explizit point of initialization.
With the given implementation probes can ask the controller for it's initialization state, so they can control, if they want to call the singleton instance which forces immediate initialization.
Someone could ask in his probe, if the monitoring has already been initialized, probe will do nothing until intialization has been triggered, e.g. if

[rju]

author Jan Waller -- Thu, 6 Sep 2012 16:10:02 +0200

Replying to [soenke.reimer|comment:1]:
> Another requirement belonging to this one is a triggered initialization
>
> In our case the monitoring.properties to be used for kieker will be extracted from ear-archive or db after the first instrumentation probe has already been run.
> So we need an explizit point of initialization.
> With the given implementation probes can ask the controller for it's initialization state, so they can control, if they want to call the singleton instance which forces immediate initialization.
> Someone could ask in his probe, if the monitoring has already been initialized, probe will do nothing until intialization has been triggered, e.g. if

This should already be possible. All that is needed would be a new singleton class with a holder object for the monitoringController, delaying teh actual call of createInstance() until needed and returning false before.

[rju]

author André van Hoorn -- Mon, 11 Nov 2013 15:31:27 +0100

Won't fix for now