Hello Bram, On Jul 15, 2009, at 14:50 , Bram de Kruijff wrote:
Great to see this project taking off. With some minor troubles I got a first integration with our application (used the dev-gateway as a template) working with the filebased server example :) This has however triggered some questions about how things are gonna work in the real world. Guess they are a little bit ace/felix borderline but IMHO relevant to ACE so I post them here.
Sure.
First, I noticed that the snapshot DeploymentAdmin uses a 'persistent' data file to keep track of DeploymentPackages between restarts of the framework. Unfortunately Felix bundle cache puts this data in the cache dir which is cleared when booting with org.osgi.framework.storage.clean=onFirstInit which is what we like do to keep things clean. As a consequence DeploymentAdmin can't keep track of things between restarts. How should we manage this? I am I doing a stupid thing by always cleaning the cache? Is Felix wrong by putting 'persistent' data in a 'cache' dir? Is there some way around this that I am not aware of?
The OSGi spec states that bundles and their states are persisted and restored when starting up again, so cleaning the cache is something you should not normally do. It is used more often during development, because then you often try to launch a framework with bundles that might still have serious bugs in them, causing updates to fail, etc. In a production environment I would say you don't need to clear the cache on every launch.
That being said, there is nothing in the spec as far as I know that mandates DeploymentAdmin to use the bundle data area, so in theory we could make that configurable. However, if you start clearing some caches, but not everything, then you get into a shady territory where some stuff is indeed persisted whilst other stuff is not. Therefore I would still suggest you don't clear the cache, unless you really want to reinstall everything from scratch. In such a case, DeploymentAdmin will get the full latest version from the server.
Second, I do not understand how to map DeploymentAdmin and the startlevel concept together. I do not see a way to manage startlevel in a DeploymentPackage and can't find a reference to it in the spec. In my current setup just puts everything in the default startlevel which is not exactly what I would want eventually. I hope someone can enlighten me :s
DA and start levels are separate concepts. One thing you could do is to actually provide some kind of "configuration information" that determines the start levels of the bundles. That configuration information could then be deployed as part of the same deployment package and sent to a bundle that translates this information into instructions for the start level service. We did not implement such a thing yet, but that should not be hard.
Greetings, Marcel
