whenConfigurationActive block invoked twice on startup about domino HOT 9 CLOSED

As explain in https://github.com/domino-osgi/domino/blob/master/UserGuide.adoc#listen-to-configuration-changes, it immediately checks, if a configuration with the given PID is available. If not, the passed function is called with an empty map. If you do not want to do anything when no configuration is available, you can simply ignore the empty map and thus the first synchronous call. As soon as Config Admin provides the required configuration, you will be called again with a non-empty map. This is essentially the same behaviour as with implementing ManagedService from the OSGi spec.

whenConfigurationActive("myServicePid") { 
  case Map() => // ignore the empty configuration
  case confMap => // do something
}

from domino.

Thank you for that answer. If this is semantically the same as pure OSGi I can live with it and the proposed solution. Note however, that on redeploy of a bundle for which a configuration exists, even the first invocation will not actually be an empty map. Both times it will be the same pre-existing configuration, which makes it a little harder to deal with but not impossible. I got around it by caching the current configuration map and comparing when this gets called. If it's the same, do nothing.

from domino.

Thanks for your insights. What you described is not ideal. I'd like to investigate this issue a bit more and will leave it open for now. Do you have, by any change, a small/simple test project to reproduce it?

from domino.

not something I can share here, but this activator exhibits the behavior:

case class Config(topic:String = "metrics",key:String = "MsgKey" ,msg:String = "Testing 123",count:Int = 10, sleep:Int = 1000)

object Config  {
  def apply(config:Map[String,Any]):ProducerConfig =
    Config(config("topic").toString,config("key").toString,config("msg").toString,
                   config("count").asInstanceOf[Int],config("sleep").asInstanceOf[Int])
}

class Activator extends DominoActivator {

  var currentConfig = Config()

  whenBundleActive {

    /// we REQUIRE the Messaging service
    whenServicePresent[Messaging] { messaging ⇒

      def servicePid: String  = "sampleModule.producer"

      val metaTypes = ObjectClass(
        id = servicePid,
        name = "Sample Producer",
        requiredAttributes = List(
          ElementaryAttribute[String](id = "topic", name = "topic", default = Some("topic")),
          ElementaryAttribute[String](id = "key", name = "key", default = Some("key")),
          ElementaryAttribute[String](id = "msg", name = "message", default = Some("msg")),
          ElementaryAttribute[Int](id = "sleep", name = "sleep", default = Some(1000)),
          ElementaryAttribute[Int](id = "count", name = "count", default = Some(10))
        )
      )

      whenConfigurationActive(servicePid, Some(new SingleMetaTypeProvider(metaTypes))) { config ⇒
        val newConfig = Config(metaTypes.defaultConfig ++ config)
        if (newConfig != currentConfig) {
          currentConfig = newConfig
          log.warn("Sample Producer starting")
          ... // do something using messaging service
        } else log.warn(s"Jitter!!!") // second invocation - happens only on (re)deploy
      }
    }
  }
}

I removed the meat, but the structure is obvious, hope it's helpful.

Thanks,

Frank

from domino.

Thank you. As mentioned, I'd like to keep this open for further investigation.

TODOs:

• Formulate desired behaviour
• Test case to reproduce
• Fix

from domino.

The internal logic of ConfigiurationWatcherCapsule already checks if the configuration has changed, and only recreates the capsule when a change has happened. It seem, this logic is currently buggy...

from domino.

I could fix the issue.

Problem was the comparison of the old and new configuration was made by using java.util.Dictionary.equals which isn't a good idea if you want a result based on the dictionaries content.

@fsauer65 Could you please verify, that the issue is fixed by master?

from domino.

I verified and can confirm that this behavior is fixed on master, thank you so much!

from domino.

Great, thank you! I'll prepare a 1.1.1 release.

from domino.