Ray, Thanks for the help. I want to clarify what sort of beast I'm dealing with here. There is no "user interface" in the exact sense that you are thinking of.
What we have here is an SDK for complex NLP processing. In order to avoid classpath problems of all sorts, we've decided to embed an OSGi container 'behind' the API, because our customer will not accept a requirement to use OSGi for their framework. There's a good deal of configuration that can be specified for this thing. You are right: it could be more robust. As things are, there are things that can go wrong. The configuration is scattered in a number of YAML files, read by a number of DS Components, in their @Activate methods. I've have not come up with an approach that avoids the possibility of falling over these problems in @Activate methods. I could make my orchestration code ask some questions about the state of some of the 'leaves' before it tries to grab the 'root', if the tree metaphor makes sense to you. Maybe the design principle is that DS activate methods must always succeed, and every component is capable of existing in an 'I'm broken, you can ask me how' state. --benson _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
